anti cutting measures

Denstjiro

Hi all

In our league we are currently experimenting with patching surtain tracks to prevent cutting corners.

At the moment we are placing poles on hazardous areas (imola chicanes for example) which would stop anyone jumping the curbs or otherwise have 'experimental lines' (we have a 2wheel-on-tarmack rule)

However this brings up another issue, drivers might accidently drive into the poles and wreck their car, possibly catapulting themselfes into traffic as well.

As a league we realy dont want another season of having to ask the stewards to invest loads of time checking on driving behaviour but we dont want to put drivers at risk either.


So my question is this, what is possible?

For example is it possible to make the poles less 'hard' so to say. in such way that it has less impact but still would force people to avoid them.

Or anything else?

I've come across something a long while ago where one could put markers on the track itself which would function as 'edges' and going over it the server would give a stop and go penalty. cannot find it for the life of me!
(for all i know it was in life for speed or something hehe)

Anyways, any help or tips would be very much appreciated :)
 
Hello
Well oviusly you can not a pole there as you said it would be unfair if someone makes a mistake and gets nailed.
The best thing to do is put curbs there or speed bumps at least it will slow them down and they will not be able to just fly threw there.

Of course if you have guys cutting then you need to send them on there way. :)

Ruben M.
 
I think that an XOBJECT (like XPITIN, XSECTOR1, ect) can be used to prevent corner cuts. Try this in the SCN file:

Code: 
Instance=XCORNER1
{
        MeshFile=xcorner1.gmt Render=FALSE VisGroup=(32)
        CollTarget=TRUE HATTarget=TRUE
//The following line (should) tell the simulator that the car made an illegal move.
        Response=VEHICLE,CORNER
}

Make sure the said object is actually there. Otherwise, you'll cause a game crash.

You don't want to use polls. One mistake and you could take out half of the field in an instant. Curbs are less hazardous, but can still take out a good portion of the field if you're not careful. The TDF file has a flag for the material that makes driving on that material illegal. If someone uses it to cut a corner, they'll receive a black flag. If I remember correctly, if someone misses enough waypoints on the AIW file, they'll be given a warning or a black flag.
 
Last edited:
Thx guys

Ruben, if it was just the same guys that would have been our solution but its not. sometimes its a new member whone needs to learn what we expect and sometimes seasoned drivers whome should know better.
Its not like half the field is doing it either, say 2 to 5 drivers overall on only 2 cutting-tracks per season.
That isnt allot and we are very lenient with accidental cuts as well but still, an unfair advantage should be taken away. especialy since our racing is so close since we pull the field together with handicaps.
The biggest issue for us is that if we review one driver his entire race we feel its only fair to review all other drivers as well to get a complete picture. and that takes up way too much time.

henche the track adjustments we are experimenting with.

Thx for that TChapman, defo will try that :)
 
Denstjiro said:
At the moment we are placing poles on hazardous areas (imola chicanes for example) which would stop anyone jumping the curbs or otherwise have 'experimental lines' (we have a 2wheel-on-tarmack rule)

However this brings up another issue, drivers might accidently drive into the poles and wreck their car, possibly catapulting themselfes into traffic as well.
Click to expand...
As a league admin I can understand you pain (in the ass) quite well.
As an example, for a few years I opted on using the Turismo version of Brianza, just because it had tire stacks. About 5 cars were killed per 2 hours of race (out of ~30) for 2 years in a row. So then I tried to go about the problem in a different manner, removing things like hazardous poles and tire stacks on some tracks and implementing speed bumps. At Monza it worked quite well, because to cut, you'd have to climb the curb while changing direction which will inevitably destabilize the car. In other places like T1 at Salzburgring... *ahem* it didn't work as planned...
Krilov_flight.jpg

Here's another example on youtube from one of the guys who made a bit of an error which ended in spectacular aerobatics. There were a few more, equally impressive.

Meanwhile there was one driver in the LMP class who barely ever bothered to take that chicane properly. He just drove straight through and hopping didn't harm him all that much... So I've now established that putting these speed bumps where you can hop over more or less in a straight line, is not efficient.

There is another way. Someone on the old RSC programmed a software package for marking legality borders on the track. Every time a driver crosses them, his name and time of the event is reported into a file on the ftp server. So later the stewards can have a look at any individual cut (name, place, time) and at the the general stats who cuts most often. That info is helpful, as stewards will know which drivers should be looked at on the replay.

Here, I found it, it was Knarf. Sadly the topic is gone, but the download is available at http://www.virtualr.net/rfactor-cut-detection-released/
The obvious downside of this, is that you can only take measures in retrospect by penalizing drivers after the race. Another downside is the complexity of the whole process. It's pretty easy to check the results, but takes some time and patience to setup the whole thing on the server as well as create 'cut files' for each track (to determine the borders of the legal track).
 
Last edited:
Thanks Pandamasque, good to hear from other admins as well.

Loved the video, not so much the footage because that looks realy bad but the music is epic :D

Yeah we recently found that program on rf-planet submitted by Knarf as well.
We are looking into it but it seems it needs quite abit of time to setup up a track this way and the stewards would have to check those entry's on a more regular basis then they do now
Now we only check if we suspect something or are informed that something went down. with such a program i fear we would be checking on things even more.

Needless to say we took appropriate actions in point reductions, DQ's and race bans but it would be so much easyer of rfactor itself (or the server) could warn a driver if they are cutting. its happening now of course but far too lenient.


I wonder,
The server penalties for cutting, they are just points on-track to identify a car cutting the track. usualy 4 wheels on the sand in a chicane.
Cant these 'points' be multiplied and moved?
 
I think there may be another problem with XCorner objects. It will penalize also drivers which didn't cut intentionally but by accident, they were pushing out by another drivers etc. In result it will work the same way like putting additional retarders onto track.
There are missing some more complex, native routine build in rF.
Even while writing own plugins, there is a problem with defining road edges. It could be done with AIW, but for most tracks AIW isn't precise enough or even is just wrong due really big differences between white line and what is defined in AIW. 1meter differences are simply unacceptable in such systems.
So, only way is to "calibrate" each track. We do that running special car around a track with small speed tracing its borders. I'm not sure it is possible to do that better. Maybe next step is to write plugin to get those data and inform drivers about any run off. But IMO each driver should know when he's out or not.
 
Try using a material with a flag of "Legal=FALSE" (defined in a TDF file). This should be more forgiving than an XCorner or physical barrier. It's the same material flag used by stuff like grass and gravel and most tracks should have it on those materials. Using it on pavement will allow a driver to hit the material by accident, but as long as no ground is gained, the driver shouldn't be penalized.

EDIT: Make sure that the said material is not the same as the racing surface. Otherwise, everyone will be penalized. Also, I remember something about a cut-track line in the AIW file that can be manipulated by the TDF when you are recording an AIW line. This line seems to work, but if the material is wrong, you'll end up having an erratic cut-line.
 
Last edited:
And as with everything else in rF, there is no proper documentation for how to prepare that stuff correctly?
 
LesiU said:
And as with everything else in rF, there is no proper documentation for how to prepare that stuff correctly?
Click to expand...
So true, so true.

EDIT:
By the way, I think I saw a Youtube video on how to make AIW files and identify cut-track points.
 
Last edited:
A small update to complete the circle.
We did two test races with poles and it went better then expected. Some drivers got an exit due to the poles but these where more concentration issues or silly mistakes (according to them) then the poles beeing too dangerous. (10+29 laps)
Overall a good feedback on the project although as admins we still fear innocent bystanders could get sucked into someone else's mistakes.
The cutting was gone obviously in the turns we placed the poles.

We came up with a compromise.
We will be increasing penalties for deliberate cutting, severe penalties which should encourage anyone driving less on the edge and more in the spirit of the league.
And on one or two tracks there will be poles if surtain turns are deemed too inviting.
 
Cut detection, it is a tricky subject for several leagues but we dont share enough about that !
In old drivers spirit league, we are trying several solutions as we had the same problems with poles.
Our main solution is to use a program that detect cuts with the replay file of a race. This tool is not almost complete as it is a linux binary but detection works as well.
This tool take a .vcr replay file and the track files with reference points generated by rf track creator of knarf.
So you dont have to configure all the knarf's rf cut detection tool and it dont load your dedicated server.
Just make the reference points for cut detection, do the race. And after the race give the .vcr and reference points files to cut tool and you wil have one file per driver with cuts !

Here is an example:
***** BEGIN for Ben Paulet : 8 cuts, 2 events ******
<< pit out at 0min28s
xx cut in at 14min39 , cut out at14min41
xx cut in at 28min54 , cut out at28min55
xx cut in at 38min55 , cut out at39min1
xx cut in at 40min0 , cut out at40min1
xx cut in at 41min23 , cut out at41min24
xx cut in at 53min40 , cut out at53min48
xx cut in at 53min49 , cut out at53min51
xx cut in at 55min31 , cut out at55min50
>> pit in at 62min33s
***** END for Ben Paulet ******

After this, we use to watch the replay file in rfactor to verify each cuts in order to validate or unvalidate it. We are 4 to verify it and discuss it if needed, so it takes some time but last year we watched each driver replay to detect cuts ! so now, we got the potential cuts to verify.

Another solution to prevent from cutting is to put post to explicitly indicate the limit of the track, in some curbs or chicane it can be well appreciated. Those poste are not collidable, it is just for cut info !


So we take the option to analyse cuts after the race with some info on the track but nothing collidable. It takes some time but it is another choice i wanted to share !
Our tool need some more dev in order to be really efficient, and i have to port it to windows !
 
fastorro said:
Another solution of our community, rfCurDetection by Knarff & CutViewerHTML by me.

1.- Create points with tool rfCutDetection & use serverdetector, all this by Knarff.
2.- To post cuts to people, I have created a HTML utility, here: http://www.campeonatopdlr.com/rFCutDetection/
Click to expand...
Nice HTML viewer :)
I was thinking about adding an HTML viewer to the cutdetector just a week ago. Is your downloader publicly available for download ?
 
knackko said:
Nice web page.

Do you review the cuts with replay after? how do you use this tool to decide of penalties?
Click to expand...
Knackko,

You should download the tool at : http://rfplanet.appspot.com/#addonmodrFCutDetection
It has some documentation that will clear things up.

In short. It only helps admins to see who cutted much.

After the race you (as the admin) open up the cutviewer (or the HTML viewer from fastorro which I just found can be downloaded here http://www.campeonatopdlr.com/rFcutDetection/CutViewerHTML Release20110729.7z). This gives an overview of all cuts.

The included cutviewer also gives the total number of cuts for each drivers. In our league we only look at the ones with a lot of cuts.
Now you also open the replay in rFactor and you review the cuts (the timings can be used to fast forward to the correct time).

After this we decide if a penalty is needed (time penalty (using "The Punisher"), now Q for next race, pitstart for next race, ...)

greetings,
Frank
 
Frank

I know all this tools :), as I said in previous post, I use the mapcreater and the mapchecker to create the cut files and it works great.
The difference in my process is that I made a detection tool which read the vcr file from the server and read the cut files to determine the cuts !
I did this program because we decided to not install serverdetector, using vcr file gives more time to make the cut files and admins dont have to take care of the tool before the race. So in fact, we have the same process of detection but the detection is delayed for us after the race. At this time this program only runs under linux, but can be ported to windows (just a mater of time and some dev capabilities :) ).

The ouput files of my program can not be imported in cutviewer because of the format, but I think I will make it possible, because your viewers can be a good first overview of the cuts before viewing it in rfactor, it can be a good first filter for false positives !

With my bad english, I should replace cut in by on track and cut out by off track.
 
I know nothing about this (not an admin, track editing limited to using BTB to create one track) but it made interesting reading. I wondered if it would be possible to automate the whole thing (no objects added to the track file, no need to create cut files) by reading the replay files and working out the line the majority of drivers take round each corner the majority of the time - anyone inside that line is probably cutting the corner. Add a bit of fuzziness - a margin of so many mm, ignore the cut if there is a collision in the previous few seconds, ignore the cut if the car is going x% slower than the typical speed (because they're going sideways or something!) and you'd have a reasonable likelihood that the driver had cut the corner. Add a bit more fuzziness - doing it every lap shows it's deliberate cutting; once or twice in a race, on different corners is "a racing incident" - before handing out any draconian penalties :eek:
 
Seven Smiles said:
I know nothing about this (not an admin, track editing limited to using BTB to create one track) but it made interesting reading. I wondered if it would be possible to automate the whole thing (no objects added to the track file, no need to create cut files) by reading the replay files and working out the line the majority of drivers take round each corner the majority of the time - anyone inside that line is probably cutting the corner. Add a bit of fuzziness - a margin of so many mm, ignore the cut if there is a collision in the previous few seconds, ignore the cut if the car is going x% slower than the typical speed (because they're going sideways or something!) and you'd have a reasonable likelihood that the driver had cut the corner. Add a bit more fuzziness - doing it every lap shows it's deliberate cutting; once or twice in a race, on different corners is "a racing incident" - before handing out any draconian penalties :eek:
Click to expand...

Interesting, you try to bring some interpretation of the driver lines in the detection but not so easy to do and have some doubt to detect everything well, if you overtake a driver, you will be out of the line, so it will be detected as a cut?

There is no draconian penalties in our method, as we always review the action, the cut tool gives us a timeline of cuts to verify before putting any penalties.
 
I see what you mean. This marvellous piece of software once it had recognised the racing line would have to allow you inside it on entry or exit. It would need to be even smarter and work out where the apex was, as long as you weren't inside the line at that point you'd be OK.

Hmm, carry on with the manual methods chaps :(
 
Seven Smiles said:
I see what you mean. This marvellous piece of software once it had recognised the racing line would have to allow you inside it on entry or exit. It would need to be even smarter and work out where the apex was, as long as you weren't inside the line at that point you'd be OK.

Hmm, carry on with the manual methods chaps :(
Click to expand...
Actually my first versions testversions of the cutdetector did work without setting cutfiles first.

The first version of the cutdetector (which never was released) read in the AIW file of the track. This file is used by the AI to drive around. This file contains the ideal line the AI can follow + the boundaries of the track. The first version used those boundaries to check for cuts. I think I tested the tool on some version of Zandvoort in the beginning and for that track that worked really great. But for other tracks those AIW files where just really bad and thus the cutdetection worked really bad. That is why I changed it to the system in which you have to create your own cutfiles first.
 
knackko said:
Frank

I know all this tools :), as I said in previous post, I use the mapcreater and the mapchecker to create the cut files and it works great.
The difference in my process is that I made a detection tool which read the vcr file from the server and read the cut files to determine the cuts !
I did this program because we decided to not install serverdetector, using vcr file gives more time to make the cut files and admins dont have to take care of the tool before the race. So in fact, we have the same process of detection but the detection is delayed for us after the race. At this time this program only runs under linux, but can be ported to windows (just a mater of time and some dev capabilities :) ).

The ouput files of my program can not be imported in cutviewer because of the format, but I think I will make it possible, because your viewers can be a good first overview of the cuts before viewing it in rfactor, it can be a good first filter for false positives !

With my bad english, I should replace cut in by on track and cut out by off track.
Click to expand...
Aah I see.
Not sure what the advantage is that you can create the cutfiles after the race but oh well :) Everyone hase some other needs I guess :)

We always make them before at least 7 days before the race and let the cutdetector run all the time. After we created the cutfiles we inform our drivers where they have to look out especially + since the cutdetector is running all the time they can review their cuts after doing a testsession online. That is also the reason I will check out that HTML viewer, much easier for our drivers to check their cuts after a testsession.
 
I always got a kick out of driving off the cliff at Lienz and then getting a track cut penalty when you finally landed, as if flying off the cliff wasn't a big enough penalty.
 
You must log in or register to reply here.

Back
Top