Server-side setup validation

[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:
When the driver leaves the garage to join the race, LFS sends the setup to the server.
The server passes the setup data to an external add-on (using InSim).
The add-on checks the setup against the local rules.
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.

[Bob Smith]

Sounds good to me.

[mikey_G]

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

[MAGGOT]

+1 from me.

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

[Woz]

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.

[Inouva]

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:
When the driver leaves the garage to join the race, LFS sends the setup to the server.
The server passes the setup data to an external add-on (using InSim).
The add-on checks the setup against the local rules.
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

[Mille Sabords]

@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

[wsinda]

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.
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 (http://www.lfsforum.net/forumdisplay.php?f=8)). 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.

[AndroidXP]

Yep, sounds good.
Especially the last point:
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. :)

[Bob Smith]

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.

[AndroidXP]

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 :)

[Bob Smith]

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.

[duke_toaster]

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.

[benja-man]

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.

[duke_toaster]

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

[wsinda]

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.

[duke_toaster]

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.

[rjm1982]

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_angry_angel]

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.

[ACCAkut]

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

[Bob Smith]

^^^ Sounds better.

[duke_toaster]

Rather similar to my idea :P

[wsinda]

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.

[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...

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

[the_angry_angel]

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 :shrug:

[rjm1982]

Even then, its not part of the core, and by default, will be seperated from the core, making it ingerently limited.

Look to FPSs for guidance here...quake, unreal, tribes (the best as far as scripting goes). They all are built around being able to be scripted. Mods created, all kinds of useful client and server-side tools...and none of them have had a "cheating problem" associated with the scripting stuff...so thats obviously not a reason to ignore that segment...

I need to learn more about insim...I've used a few of the tools created for it, but never delved in on my own. I may be speaking out of my league, but I can't imagine it's as good as having access to the core a scripting engine would provide.

[wsinda]

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.Oops, made a thinking error there: the script must be pretty limited in its power, if you really want to keep the setup confidential. For instance, the function can't be allowed to make an HTTP call, because that enables a malevolent script to send the setup data elsewhere.
Even then, its not part of the core, and by default, will be seperated from the core, making it ingerently limited.I don't think of InSim as limited. You can do a lot with it, both for retrieving data from the engine and for controlling the game engine. Have a look at the CTRA X-system; it uses InSim's possibilities to the fullest.

The downside to InSim is that writing an application is not for beginners. (The upside is that the performance penalty is lower than with scripting.) That could be solved by building a scripting engine of top of InSim, like the_angry_angel did with luaLFS (http://www.lfsforum.net/showthread.php?t=19832).

EDIT: Hm. I may have been talking nonsense. Had a look at UnrealScript and TorqueScript, and they look far more advanced than where LFS is now.

To get back to the original topic, LFS would need an extra feature: to let the client execute a piece of code that it gets from the server (which may have got it from an InSim application). I expect this will be very complicated, so it will have to wait until S3 is designed.

[danben7]

I would absolutely LOVE a "force X setup"

[Forbin]

I really don't understand the appeal of forced setups. More realistic ranges and resolutions? Perhaps. But as I've said before, different people require different things from the car and have different equipment.

[danben7]

I really don't understand the appeal of forced setups. More realistic ranges and resolutions? Perhaps. But as I've said before, different people require different things from the car and have different equipment.

it's just an option.

there's nothing wrong with more options.

[Zen321]

+10

Very good idea.
For some leagues, it would be good to have the same setup for everyone, seeing who is the best with a particular type of car.

[DeadWolfBones]

Big +1 from me, as it's been every time it's been brought up. :)

[bunder9999]

did anything ever happen with this? i know airio can do some of this stuff (tire type, etc), but i'm looking for something that can verify the entire setup, maybe with md5 or some sort of hashing.

[NightShift]

I think currently with InSim you can only check some select params out of the whole setup.

[Woz]

If this were implemented it opens whole new areas in LFS.

Things like:

- Race series where handycaps are put in place based on position in the last race etc to balance racing.
- Spec racing where every car is known to be exactly the same.
- Things like the Baby Mini & GT series can be enforced properly and become new "car" types.
- Block unrealistic set options or only allow settings in specific ranges. Such as the V8s choice of 3 diffs etc
- Hell, even the cruise servers benefit as they could bodge a form of tuning with this via hanycaps and locked sets.

[danthebangerboy]

It must be possible though surely, i mean LFSTweak allows you to edit things, then it must, as an external program, be able to 'read' whatever it needs to from LFS to allow changes to be made to cars.

If this info can already be read and made sense of by a program, which im presuming it must be in order for tweak to work, then im guessing that something could be written with insim or something that just reads the setup data from connecting players and if the data isn't inside the paramaters set by the server then you can't join.

[Bob Smith]

If you were to mandate an external setup checker app that was to run in the background and transmit "ok" or "fail" messages to the server, in order for you to join the server, then I think this would be possible. Not exactly convenient though, forcing people to download this in order to join the server. Maybe would have some use in leagues.

[bunder9999]

If you were to mandate an external setup checker app that was to run in the background and transmit "ok" or "fail" messages to the server, in order for you to join the server, then I think this would be possible. Not exactly convenient though, forcing people to download this in order to join the server. Maybe would have some use in leagues.

works for me, anyone feel willing to code one? :thumb: