See updated lapper code and source patch file in first post.

Hey KK,

Remember that we will be migrating to lapper v8.744 from Thursday onwards to take advantage of the Car Reset and Handicapping modules that we've created.

The drift and race PB files are going to convert to an internal database, but I'll modify the !top command to use your current car as the default and we migth create some export functions for you.

I've just submitted a patch to Gai Luron for inclusion of the qualMins var, as well as changing the Car Reset and LapsLeft code to use a new raceMins var.

Quote from Tim NL :

Hi,
I found a small bug in 5.844
The new LapperVar's in release 5.844 will not work so fine.

RaceLaps = number or laps for a race
QalMins = number or minute in a qual
racelapsleft = Race lap left before end of race

getLapperVar( "RaceLaps" );
getLapperVar( "QalMins" );


The number of race laps are only show when you in a race and the QualMins don't show anything.

I tested white the next script.
Type !test in a qual session gives RaceLaps :0 and QalMins :
Type !test in a race session gives RaceLaps :6 (OK,is number of racelaps ) and QalMins :
After a race or when race is not started ( nobody on the track) the number of race laps will stay on 0.
The getLapperVar( "QalMins" ) stay always empty.

CASE "!test":
cmdLFS( "/msg RaceLaps :" . getLapperVar( "RaceLaps" ));
cmdLFS( "/msg QalMins :" . getLapperVar( "QalMins" ));
BREAK;

Hey there Tim,

I think you have a spelling mistake, in that the var is "qualMins", with a "u" in it.

Here's a summary of how it works after the modifications to the code for the Car Reset functions:

When you start a qual or race, InSim sends an RST packet. If its a qual session, then the QualMins variable is set to the number of minutes, and RaceLaps will be 0. These vars are transposed into the currRace object and can be used to determine if a race is in progress. The qual session will run until the time runs out.

If it is an actual race, then RaceLaps & RaceLapsLeft will be set based on the number of laps or time that is set out in the InSim.txt file (cut & pasted here), and QualMins is used slightly differently.

Now if the race is lap dependant, currRace.raceLaps will contain the original value, and currRace.raceLapsLeft will contain the ACTUAL number of laps remaining (decreased when leader passes the finish line).

Things get tricky when it's a timed race. When that is started, currRace.raceLaps will contain the original value, currRace.qualMins will contain the ACTUAL time remaining (we could change that to a raceMins var easily enough), which again is decreased when the leader passes the line (in fact we should decrease it after anyone passes the line).

If the race time is LESS THAN 5 MINS, then raceLapsLeft is set to 1. This is due to the uncertainty of how long a given lap would take when accounting for last few lap crashes or other unforseen incidents.

Does that sort of explain it?

Hiya,

As people seem to be posting snippets from their LFSLapper.lpr files on these forums, do you think it might be a good idea to move the $PubStatIdk variable into the config.ini file for added security?

Then we don't have to worry about people posting .lpr files to public forums.

Code updated to include handling of timed races as well as long races. The 30 second penalties will now be applied when a timed race has less than 5 minutes remaining:

CODE IN FIRST POST

Last edited by Krayy, Wed, 29 Jul 2009 07:10.

Updated code to make it more user friendly for the drivers using Buttons:

Last edited by Krayy, Mon, 20 Jul 2009 09:17.

NOTE: This code is for Lapper version 5.844, with the supplied Patch file applied
Hi all,

As a follow on from the Custom Penalties thread, here is the code to add penalties for racers who use Car Resets. This comprises a patch to the stock 5.844 source, along with the code below to be added at the bottom of the LFSLapper.lpr file.

The reasoning behind this patch is that we wanted to ensure that someone who used car resets during a race did not get an unfair advantage by having new tyres, damage repair etc over a racer who has run a clean race but who may be suffering from wear and tear of the tyres or car.

To that end, the code will allocate a Drive Through penalty when a reset is used during a race, but this is substituted with a 30 second time penalty on the last lap of a race as a Drive Through on the last lap is automatic disqualification.

The code also allows for different penalties if the racer uses the reset option too many times (the $MaxCarResets parameter in the LFSLapper.lpr file) where you can /spec them or whatever by changing the lfsCmd in the OnMaxCarResets Event.

To use the attached Patch file, you will either need to use TortoiseSVN and apply it, or just go through the source manually, as it's all pretty self explanatory.

Last edited by Krayy, Wed, 5 Aug 2009 01:15. Reason : Additional updates

Here's an idea for an improvement and also a request for the best way to do it in our install:

We have a mix of beginner and experienced racers and want to enable car reset, but for only a certain number of times per race, and when a racer does reset, to flag a penalty.

Now the most obvious way to do this is to write a handler in managePacket.cs for a CRS events and a hook in loop.cs then process it from there. I would most likely put an entry in the LFSLapper.lpr to set the type of penalty (stop/Go, Drive Through, 30 secs etc) and the number of resets allowed per race.

The question is whether this is the only way, or can it be done via a plugin so that we don't exclude ourselves from future releases?

Okay,

Obviously I'll be getting a new monitor when I upgrade my PC, but in anticipation of that I might spring for it now. Question is, will a widescreen 22"+ help me in LFS (i.e. make is easier to hit apexes, set entry points etc). I'm currently using a 17" 4:3 and find that spotting vanishing points or apexes a bit hit & miss. Also having no peripheral detail might be part of the issue.

Also is 1680x1050 enough or go for full HD?

Anyone got any before/after stories when they changed to a widescreen monitor?

Good-o, and thanks for the taking the time to answer.

Great tool BTW. Very useful.

Quote from Bob Smith :

The setup guide, like almost everything else I've done, really needs updating. There relationship between 'optimal' frequency and mass is debated, and only a guideline....

For us noobs at using VHPA Is it possible to update VHPA to have a slider for target frequency in Hz, tied to the ride height (spring length?)? Or is that too broad an area to tune by?

i.e. I could set a ride height of 160mm and a target Hz of 2.1 and choose hard or soft, and it could calculate spring and damper rates?

Also, with acceleration, is there any way that you can adjust the gear selection tab so that we could set a distance of the longest straight and get it to calculate the optimum gear ratios for max acceleration and top speed over that distance?

Hi guys,

For my first skin, I was inspired by the cutaway image on Wikipedia for the Mini and decided to do have a bit of a laugh and make up a naked UF1.

This is the first cut, so any suggestions on how to improve or additions I can make would be appreciated.

As a recreational motorcyclist, I have more of a tendency to use the engine note to gauge my shift points.

Problem is that I can also clutch less shift on the bike, whereas I now find myself being very conscious about the "clutch in-shift-lift-clutch out-wait for clutch to fully engage-power on".

This is more tricky on the H-gated cars as there is a decent gap between shift and clutch biting and is a bit too much to think about with 3 or 4 others on your bumper (yeah right, as if I'm ever at the front of the group :razz.

I had a WR for about 5 hours on WE1 using the UF 1000. Damn I felt good for a while

What I feel sorry for is the demo driftorz that won't have the chance to drift in the LX-6. Now THAT will make a man out of ya and eat the XRT for breakfast, lunch and Thanksgiving

One area in which I'd like to give more kudos during AutoX is in jump distance. Packet would be sent after driver has travelled more than the length of his/her car in the air and would include:

- Distance "flown"
- Object type used to launch (if possible)
- Object ID (if applicable)

So driver X hits a jump and flies 12 metres gets "You should be a s tunt driver".

Driver Y hits a barrier (Obj type = barrier), flies 10 metres and gets "Driver Y has left the racetrack in spectacular fashion"

Driver Z goes over a hump and gts airborne for 6 metres gets "Yeeeeeee-haaa"

...or something like that. Points can also be scored for distance off jumps.

What I would like to be able to do is to get more information from the IS_AXO packet where we can see:

- Object type enum (red cone, blue cone, tyre, etc)
- Unique object ID

This would enable a system where you can give more/less custom penalties based on what object the driver hits.

Also do the IS_AXO packets get sent for any custom layout object when not in the Autocross track (ie. KY, SO or BL)?

In my case, what I would like to do is to create a custom layout on say BL2 where certain cones would reduce lap times, and tyres raise them. This way we could place a blue cone (-4 secs) in btween 2 lines of tyres (+1 sec) just wide enough for an UF1 to get through, but not an RB4. This would give an advantage to the UF1 to make up time.

Conversely, the RB4 could use a ramp to reach a red cone (+2 secs) on top of a stack of tyres. Not fast enough and he knocks the tyres down.

Quote from zeugnimod :

And how can you determine that? There are so many factors that can't be taken into account by a program. There would be many unjustified kicks/bans.

Something like this has been suggested countless times already anyway.

Hmm, didn't show up in any searches.

I think what I'm getting at is that is an InSim app, you could count the # of unique contacts and then calculate how many occurred over say 2 or 3 seconds and then use that to deliver a warning for barging.

Put this in the wrong forum:

I would like to see InSim flags for contact events so that we can track who has multiple car-to-car contacts over a certain time period and either report the incident, or kick the driver. This will help eliminate barging tactics.

Suggested format something like:

struct IS_CON // CONtact (Player hit something)
{
byte Size; // 8
byte Type; // ISP_CON
byte ReqI; // 0
byte PLID; // player's unique id

byte IdHit; // unique id of object hit
word Speed; // Speed delta
short AngVel; // Angle object struck at
};

If it is car-to-car contact, then a short algorithm to determine who hit the other from the contact angle and speed could determine who gets the contact packet.

As an aside, this could be used to create a Demo Derby mod if we also get Race Flags for damage done, i.e. an enum depicting damage to shocks, tyres, body, engine etc, and an int for determine amount of damage including disabling the target vehicle.

I would like to see InSim flags for contact events so that we can track who has multiple car-to-car contacts over a certain period and either report the incident, or kick the driver. This will help eliminate barging tactics.

Suggested format something like:

struct IS_CON // CONtact (Player hit something)
{
byte Size; // 8
byte Type; // ISP_CON
byte ReqI; // 0
byte PLID; // player's unique id

byte IdHit; // unique id of object hit
word Speed; // Speed delta
short AngVel; // Angle object struck at
};

If it is car-to-car contact, then a short algorithm to determine who hit the other from the contact angle and speed could determine who gets the contact packet.

As an aside, this could be used to create a Demo Derby mod if we also get Race Flags for damage done, i.e. an enum depicting damage to shocks, tyres, body, engine etc, and an int for determine amount of damage including disabling the target vehicle.