This suggestion is not about a certain change to LFS. Rather, it's about a mechanism that will make a number of other suggestions possible, such as:

• Mandatory use of a standard setup.
  
• Enforce particular settings that have been prescribed for the league (e.g. standard tires or gear ratios).
  
• Limit setup options for road-going cars.
  
• Lock out particular settings that are deemed unfair or unrealistic (e.g. hybrid tires on road tracks, low brake force).
  
• Enforce handicaps for individual drivers.

The general way how this would work is:

1. When the driver leaves the garage to join the race, LFS sends the setup to the server.
   
2. The server passes the setup data to an external add-on (using InSim).
   
3. The add-on checks the setup against the local rules.
   
4. If the setup is not acceptable, the add-on spectates the driver, and sends a message to explain what is wrong with the setup.

The advantage of this construction is that Scawen doesn't have to look at each suggestion, decide if he wants to program it, and spend time making it. The same holds for other ideas in this area that may come up in the future.

Possible extensions:

• The add-on modifies the setup to make it compliant, and sends it back to the driver.
  
• In the list of servers, you see a flag that indicates that the server uses setup validation.

Sounds good to me.

I like it a lot, there is a definite interest in spec setups I think.

+1 from me.

I'd love to see some spec racing, and a real way to enforce reward weight.

I raised a similar idea recently TBH. One that would allow insim control over player setups on the server.

I think it needs insim control so you can lock down individual settings. Such as only allow one final drive but allow drivers to change gears etc.

Quote from wsinda :

This suggestion is not about a certain change to LFS. Rather, it's about a mechanism that will make a number of other suggestions possible, such as:

• Mandatory use of a standard setup.
  
• Enforce particular settings that have been prescribed for the league (e.g. standard tires or gear ratios).
  
• Limit setup options for road-going cars.
  
• Lock out particular settings that are deemed unfair or unrealistic (e.g. hybrid tires on road tracks, low brake force).
  
• Enforce handicaps for individual drivers.

The general way how this would work is:

1. When the driver leaves the garage to join the race, LFS sends the setup to the server.
   
2. The server passes the setup data to an external add-on (using InSim).
   
3. The add-on checks the setup against the local rules.
   
4. If the setup is not acceptable, the add-on spectates the driver, and sends a message to explain what is wrong with the setup.

The advantage of this construction is that Scawen doesn't have to look at each suggestion, decide if he wants to program it, and spend time making it. The same holds for other ideas in this area that may come up in the future.

Possible extensions:

• The add-on modifies the setup to make it compliant, and sends it back to the driver.
  
• In the list of servers, you see a flag that indicates that the server uses setup validation.

And the keyboard and mouse player , if dont use "low force brake" how do think we breake propely without block the wheels??

I specialy use low force brake in the FXR in AS3 , because i dont have the pedals to regulate the brake presure

-1 for me
________
Mercedes-benz mb100 specifications

@Inouva: Brake help would save you there

The OP only suggested ways to check the setup when you leave pits, but what is done after that with the data collected is up to the insim app / server side to decide.
So nothing to worry about for your overall LFS time, but more opportunities to developp / balance racing on specific servers.

+1

Quote from Woz :

I raised a similar idea recently TBH. One that would allow insim control over player setups on the server.

Sorry if I duplicated your idea (got a link?). I only checked the stickied threads on this subforum.

Quote from Inouva :

And the keyboard and mouse player, if dont use "low force brake" how do think we breake propely without block the wheels??

I know, I have been a mouse driver until recently. I also like brake force the way it is (as you can see in this thread). But there is demand for this kind of thing.

My suggestion is to make it possible to check the setup at the server. The admin can choose to restrict setups (but he will need some extra tooling for it). Then it's your choice to join and race at this server, or go to an "unrestricted" server instead.

Yep, sounds good.
Especially the last point:

Quote from wsinda :

• In the list of servers, you see a flag that indicates that the server uses setup validation.

is important though, so players with team setups who rather not have their setups "stolen" can avoid these servers.

There's no need for the software (which would only have to be written once and then people make scripts for) to cache the setup after it has been checked.

Of course not. But as LFS would send the setup via InSim (I guess), "the software" could be written by anyone, and they could thus do whatever they want with the setup files. Therefore this flag is vital

My line of thinking was it person x creates the software without this feature, and person y runs the compiled binary on there server, it can't happen. Of course all setups sent can be captured through packet sniffing anyway, although there isn't usually an automated process reading your set without you having to manually send it. Anyone can just put some initials in their server name though, I don't see a need for a seperate marker in the server list. You could back it up with a warning text you agree to when entering the server before you join the race.

I'd rather it not be handled by InSim, but it's a good idea to have forced sets.

Each individual item could be forced or held in to a particular range.

Although I would like to see some unrealistic options removed, end of.

You could have a prompt before the setup is sent, people who don't want to send it can leave the server without or go to the garage to select another set.

If it was handled by the server rather than an InSim app, there's no reason for a prompt.

Quote from duke_toaster :

If it was handled by the server rather than an InSim app, there's no reason for a prompt.

The point of leaving it to an InSim app is that when it comes to setup restrictions there are myriads of variations. Some examples:

• Fixed setups, one for each car in the LRF class.
  
• XFGs must carry extra weight, to even out against the UF1.
  
• RB4s can't use hybrid tires, so XRTs stand a chance on a rallycross track.
  
• Setups that make use of the "high nose" bug are forbidden. (Okay, that bug has been fixed, but imagine that a new physics flaw is discovered.)
  
• Drivers who have already won a race this month must carry one passenger.

You can't expect Scawen to put all of that in LFS. And even if he did, the next day someone would get a great idea for a league with a new kind of setup restriction.

If you leave all that to an external add-on, things will be much more flexible. There may even be several add-ons, to cater for different needs. And it will not burden Scawen, so he can spend his time on other nice features.


The downside is, indeed, that setups can be "stolen": the creator of the add-on and the server admin could decide to store the setups for their own use. Does that create a new problem? I don't think so. My guess is that setup data is already exchanged between client and server, and possibly even among clients. (LFS needs at least part of the setup to simulate a car's behaviour between updates.) Therefore, anyone who is adept at packet sniffing or memory peeking can already steal your setups.

You might say that my suggestion makes theft easier. In that case it would be good if LFS gave a warning when you connect to a server that uses setup validation.

Maybe it could be something like

<XFG>
HandicapBallast==50
FTyreComp!=Hybrid
FTyreComp!=Knobbly
RTyreComp==Road_Normal
<XFG>

For an XFG with 50kg of lead and no hybrids or knobblys on the front and road normals only on the rear.

OK, it could get a big file. And an admin should be able to upload it to the host whilst connected, or at least edit it.

I was thinking of this last night...I actually fell asleep thinking about it...and I had not even seen this post yet...just something that crossed my mind.

But here's what I came up with for a way to make the setups work.

It would actually have to be built into LFS at the core, not just using insim.

Basically, someone would first create the setup and the "rules" for the setup.

The rules would actually be part of the .set file. When that set file is loaded, unchangeable options would be grayed out, or options with specific choices/ranges would only allow those things to be changed. If you wanted, you could change them (after a warning), but it would update the rules section of the set file, so it would no longer be validated as the same setup.

As far as in-game checking. A hash could be created based off of the rules (not the entire set) and sent to the server. The server could then verify that the hash is correct based off of the rules it is setup for.

One thing about this idea that makes it nice, is since the server is just checking a hash, it could easily and quickly check against multiple rule sets. In a kart league i raced in when I was younger, you could chose between 3 gear sets, but based on those gear sets, your tire choice was dependant. So, you could choose a higher top-end gear set, but you would be forced to use a harder compound tire, and the trade-off was a faster top end, but reduced cornering...and it produced great races (less "clone-car" feeling). So a league could publish multiple rule sets, and check to make sure you are using one of them...

This way, you get the best of both worlds.

You can verify the setup server side based on the rules, and the actual setup is never sent (so you don't have to worry if you're the kind to worry about your setup being stolen). It also reduces bandwidth and CPU cycles needed to verify it.

It would need one last failsafe. Every time the setup is loaded, it would need to check that the actual setup is in compliance with the rules (so it couldn't be hacked, by someone externally changing the file without changing the rules section..but that would be a very fast, client-side only check.

The last time I looked, the setup size was only about 140 bytes or so in size. Forcing this down the pipe during the normal join protocol would be fairly simple, and then setting a flag within LFS, similiar to what happens for selectable cars.

The only other thing required to polish it off, would be an export function to copy it from the client to the server for people who don't know where to find .set files. Think of it like loading a layout.

Everytime you trigger a potential change in setup event (i.e. pit out), the client could then just send a hash of the set to the server, which validates it against a known value. If it doesn't match then /spectate. Fairly simple.

Edit: That'll teach me not to refresh. My post is largely the same as rjm1982's. Ho hum. I do apologise.

To prevent unauthorized setup caching this system could work the other way round, the server sending the setup reglementations and each LFS client checking the used setup itself. This would limit lag too I think

^^^ Sounds better.

Rather similar to my idea :P

I like ACCAkut's approach better. If you really want to protect setups, the check must be done client-side, and the server must send its rules. The rules are public data anyway, so snooping is not a problem.

An important issue is flexibility of rules. In duke_toaster's suggestion you can only define a range for each value. You can't fit in rjm1982's example, where the acceptable choices for one setting (tyre type) depend on the value of some other setting (gear). And rjm1982's suggestion has fixed rule sets, so driver-dependent rules (e.g., a driver with a Gold license must carry 50kg of ballast) are impossible.

You get maximum flexibility if the rules are declared in the shape of a program. Suppose that the server sends the client a JavaScript function. The function takes a setup as input, and returns a boolean result. If the server rules are simple, the admin can write the script and store it as a file on the server. For more complex rules, like the one that depends on the license, you would need an InSim app that generates a validation script on-the-fly.

It is getting pretty complicated, though. Scawen needs to incorporate a scripting engine into LFS, and make an RPC-like mechanism on top of InSim. All of this to get some extra protection of setup data.

A scripting engine in LFS would be an end-all to a huge number of "wishlist" items... I still can't believe that as mature as LFS is, and as "community based" as it is... there is no internal scripting engine...it baffles me...

...but that's another thread...

Quote from rjm1982 :

A scripting engine in LFS would be an end-all to a huge number of "wishlist" items... I still can't believe that as mature as LFS is, and as "community based" as it is... there is no internal scripting engine...it baffles me...

There have been a few attempts to create an external scripting engine, powered from insim, but as I discovered polishing it and delivering it to the masses with some good analogies was a little tricky. Maybe something to revisit I guess