This is exactly what we had planned, way back when Bob, Dylan and I were working on an intergrated telemetry/setup analysis tool. It never got very far sadly, real life got very in the way, it's great that Bob carried on with it though, even without the telemetry stuff.
Yeah, 'while decreasing braking' and 'while increasing throttle' would be minimal but correct. While applying throttle doesnt really cover it because you would be applying throttle even when doing a neutral pitch turn-in. Also technically you could have a phase 2 entry even if you were increasing throttle and turning in, for example the second part of a chicane, which would have the same damping requirements as a trail brake turn-in.
I've not had time to have much more than a cursory look so far, but it does seem quite a lot like what we had planned
Particularly the pane layout with setup parameters on the top and analysis on the bottom, with freedom to look at any analysis pane while changing any setup parameter. Like it.If I was forced to offer some constructive criticism, I'd say you've obviously done a whole heap of work on the dry equations and can spit out tons of numbers, but the next phase of development should perhaps include some workflow analysis of how people could use it to actually create setups. Maybe work on some wizards or more comparative analysis.
I'd always imagined as well have the ability to lock certain performance parameters and have the actual settings auto-change to maintain them. For example, say you know you want optimum camber for 50m radius corners, based on the track you are setting up, if you change the spring stiffness you'll change the roll and your camber setting wont be right any more, so it would be cool if you could 'lock' a part of the setup (say aero balance, or basic spring balance, or critical damping rates) and have it auto change to maintain the performance parameter you have set.
I'm not sure that the descriptions in the program correctly describe the corner phases actually, the phase in question isnt really braking while turning it, it's coming off the brakes while turning in.
So effectively the car is rolling outwards, and pitching backwards. If you consider this motion diagramatically, you can see that the only rear damper that is significantly active is the outside rear compression damping.
Basically, under full braking, both rear dampers will be maximally extended, and under full cornering the outside rear will be fully compressed and the inside rear will again be fully extended. So you can see that if you perform that transition smoothly around the outside of the traction circle, your inside rear basically stays where it is, and your inside rear goes full extension to full compression. Likewise you can also see that the outside front basically stays compressed and the inside front travels the full distance in rebound.
Hence for this transition, the rear compression damping and front rebound have the dominant effect on their respective ends of the car.
It's also some time since I thought all this through, but if memory serves, it goes like this:
Any increase in damping results in increased roll stiffness for that end of the car when the dampers are in motion, ie. increase rear damping, rear has greater roll stiffness during transients.
Which ever end has greater roll stiffness will attract a higher proportion of the load transfer. Now due to tyre load sensitivity, a wheel pair with greater load transfer will have lower overall grip.
So basically, the stiffer end has less grip, you are probably familiar with this from basic spring tuning.
So at corner-in, you're inside rear damper will go into rebound, so if you increase the rebound damping, the roll stiffness will be greater at turn-in, taking away grip from the rear and increasing oversteer.
The LFS engine does allow for distance cueing through the 'haze' setting. I suspect that screenshot was produced in engine by turning up the haze.
If someone rummages around in the memory long enough, they might find the variable that controls the distance cueing and create a fog mod.
If someone rummages around in the memory long enough, they might find the variable that controls the distance cueing and create a fog mod.
http://www.lfsforum.net/showthread.php?p=115008#post115008
That post, and the associated thread is a fairly in-depth discussion about this. Might be useful to you.
Erk, that is the freakiest way of scaling a value I've ever seen, you have any array with 65536 values in it!
Can I suggest the following:
<?php
function ShortToGear ($short){
$factor = $short/pow(2,16);
$gear = ($factor*7)+0.5;
return ($gear);
}
?>
I suspect its because you are converting a couple of binary bits into an ASCII string representation of a hexidecimal number, then converting it again into a decimal number.
I take it you havent actually got this code working yet, because looking at your code for dealing with 4 byte floats, there is no way that will work.
Really unpack() is the most appropriate function for converting any binary data type (float, short, byte etc.) into a variable.
EDIT: Just looking into it some more, there isn't any need to do hexdec(bin2hex()) anyway, because there is a bindec() function which goes straight from binary to decimal on anything up to a 4byte integer.
I take it you havent actually got this code working yet, because looking at your code for dealing with 4 byte floats, there is no way that will work.
Really unpack() is the most appropriate function for converting any binary data type (float, short, byte etc.) into a variable.
EDIT: Just looking into it some more, there isn't any need to do hexdec(bin2hex()) anyway, because there is a bindec() function which goes straight from binary to decimal on anything up to a 4byte integer.
Last edited by colcob, .
Erm, its a while since I wrote it, and its part of a general set file library that probably relies on other functions.
If memory serves, $setFile is a file pointer not a path, so you should already have done:
$setFile = fopen("../setup.set", rb);
To be honest, the function isnt really designed to be used on its own, it was just to show you how unpack() works.
The array that you get back from ReadSetData() then got sent to a function called SetDataToValues() which converts binary values to actual numerical values for things like gear ratios etc.
If memory serves, $setFile is a file pointer not a path, so you should already have done:
$setFile = fopen("../setup.set", rb);
To be honest, the function isnt really designed to be used on its own, it was just to show you how unpack() works.
The array that you get back from ReadSetData() then got sent to a function called SetDataToValues() which converts binary values to actual numerical values for things like gear ratios etc.
Have you thought of using the unpack function? You just enter a single string which represents your file format and it spits you back the array with all the values in. If the setup format changes you just change the string.
Here's mine for an early S2 patch.
I dont suppose its technically any different from yours, just skips a bit of typing
Here's mine for an early S2 patch.
<?php
function ReadSetData ($setFile){
if (!$setFile){
echo "File opening failed";
}
$setContents = fread($setFile, 132);
$setData = unpack ("@16/fbrakeStrength/crearWing/cfrontWing/x2
/csteerLock/cparallelSteer/cbrakeBalance/x1/cdiffTypeCentre
/cdiffViscousCentre/x1/cdiffCentreTorqueSplit/x2
/SgearFinal/Sgear1/Sgear2/Sgear3/Sgear4/Sgear5
/Sgear6/cpassengerByte/CcarConfig/x2/frearTravel
/frearSpring/frearComp/frearRebound/frearAR/x4/crearToe
/x1/crearTyreType/x1/cLRcamberAdjust/cRRcamberAdjust
/x2/cdiffTypeRear/cdiffViscousRear/cdiffPowerRear/cdiffCoastRear
/SLRtyrePressure/SRRtyrePressure/ffrontTravel/ffrontSpring
/ffrontComp/ffrontRebound/ffrontAR/x4/cfrontToe/ccaster
/cfrontTyreType/x1/cLFcamberAdjust/cRFcamberAdjust/x2
/cdiffTypeFront/cdiffViscousFront/cdiffPowerFront/cdiffCoastFront
/SLFtyrePressure/SRFtyrePressure", $setContents);
return ($setData);
}
?>
I think people are perhaps failing to understand, and Scawen has maybe not explained, that there is a parallel development of different versions. Scawen clearly has a non-compatible next version build in which all the big stuff (car updates, physics updates, AI etc.) get worked on, and every now again he spends some time improving usability and implementing community requests in the current compatible version.
I've always assumed that behind the series of continuous but minor improvements we've seen in the U test patch series, there has been a continued development of the major features for S2 Final. But Scawen has been keeping quiet about them so as not to get caught out like before.
Now I may be wrong, but I'd anticipate that at some point there will be a sudden release of a major non-compatible patch, and we'll all suddenly see what's been going on behind the scenes.
I've always assumed that behind the series of continuous but minor improvements we've seen in the U test patch series, there has been a continued development of the major features for S2 Final. But Scawen has been keeping quiet about them so as not to get caught out like before.
Now I may be wrong, but I'd anticipate that at some point there will be a sudden release of a major non-compatible patch, and we'll all suddenly see what's been going on behind the scenes.
Just to give you some basic equations to work from:
Acceleration (in metres per second) = Force (in Newtons)/Mass (in Kilograms)
So at any given moment in your simulation, to work out the instantaneous acceleration, you just need to know the vehicle mass, the force being exerted at the contact patch and the forces resisting forward motion (ie. air resistance, rolling resistance etc.)
To work out your linear force at the contact patch, you need to work from the engine down. You'll need either an algorithm or a table which can tell you what torque the engine will output at a given RPM (at full throttle). This can be either a look up table which interpolates between values, or a fancy equation like what Scawen does.
From this torque value you need to multiply by the current gear ratio to give you torque at the driveshaft. Engines are nearly always geared down, so torque at the drive shaft will be greater, and RPM lower.
Its preferable to use units of Nm for torque just to make things easier. Now to convert this driveshaft torque to linear force at the contact patch, you need to divide by the wheel/tyre radius.
So if you have a driveshaft torque of 1000Nm, and a tyre radius of 0.5m, you will get a linear force pushind the car forwards of 2000N.
linear driving force = (engineTorque*gearRatio)/tyreRadius
Resistance force from the air is basically proportional to the square of the velocity, so your equation for resistance is simply CdA*VelocitySquared (velocity in m/s). CdA is the coefficient of drag and is simply a constant that depends on the size and shape of the car, you can probably just play around with that value to get reasonable behaviour, or do some googling to find out what the typical values are for drag racers.
So now your actual net force (N)= Driving Force - Resistance Force
So your vehicle acceleration(m/s/s) = netForce(N) / vehicleMass(kg)
Now the question of turning these equations for a given moment in time into a continuous simulation is one I havent got much experience of, but if I was going to set out to do it, it would be like this.
We basically need to perform these equations to determine acceleration at one moment in time, then assume we have continued to accelerate at the same rate until the next time we calculate the acceleration, which should ideally be a fixed length of time, for simplicity of coding, although this may be difficult in javascript.
So assume we are travelling at 50m/s, and our calcs reveal we are accelerating at 10m/s/s. At that rate, in 1 second we would be travelling at 60m/s, but say our calculation rate is 50hz that means in 0.02s we will have increased our velocity by 10*0.02, or 0.2m/s.
So we add that to our velocity giving us 50.2m/s and start all over again.
The main difficulty with this approach is getting to and from stationary, as if your velocity is 0, all kinds of things go horribly wrong with the calcs, but given that you are doing drag racing, you can probably just script the start to give the car a small initial velocity, then then the simulation take over from there.
A further complication of the timestep method is if you cant rely on fixed lengths of time between your calcuations, then you need some method of keeping track of how much actually passed between frames, and putting that value into the equations. Again, I dont know if javascript in max can do this.
Anyway, enough rambling. Sounds like an interesting project, good luck with it.
Acceleration (in metres per second) = Force (in Newtons)/Mass (in Kilograms)
So at any given moment in your simulation, to work out the instantaneous acceleration, you just need to know the vehicle mass, the force being exerted at the contact patch and the forces resisting forward motion (ie. air resistance, rolling resistance etc.)
To work out your linear force at the contact patch, you need to work from the engine down. You'll need either an algorithm or a table which can tell you what torque the engine will output at a given RPM (at full throttle). This can be either a look up table which interpolates between values, or a fancy equation like what Scawen does
.From this torque value you need to multiply by the current gear ratio to give you torque at the driveshaft. Engines are nearly always geared down, so torque at the drive shaft will be greater, and RPM lower.
Its preferable to use units of Nm for torque just to make things easier. Now to convert this driveshaft torque to linear force at the contact patch, you need to divide by the wheel/tyre radius.
So if you have a driveshaft torque of 1000Nm, and a tyre radius of 0.5m, you will get a linear force pushind the car forwards of 2000N.
linear driving force = (engineTorque*gearRatio)/tyreRadius
Resistance force from the air is basically proportional to the square of the velocity, so your equation for resistance is simply CdA*VelocitySquared (velocity in m/s). CdA is the coefficient of drag and is simply a constant that depends on the size and shape of the car, you can probably just play around with that value to get reasonable behaviour, or do some googling to find out what the typical values are for drag racers.
So now your actual net force (N)= Driving Force - Resistance Force
So your vehicle acceleration(m/s/s) = netForce(N) / vehicleMass(kg)
Now the question of turning these equations for a given moment in time into a continuous simulation is one I havent got much experience of, but if I was going to set out to do it, it would be like this.
We basically need to perform these equations to determine acceleration at one moment in time, then assume we have continued to accelerate at the same rate until the next time we calculate the acceleration, which should ideally be a fixed length of time, for simplicity of coding, although this may be difficult in javascript.
So assume we are travelling at 50m/s, and our calcs reveal we are accelerating at 10m/s/s. At that rate, in 1 second we would be travelling at 60m/s, but say our calculation rate is 50hz that means in 0.02s we will have increased our velocity by 10*0.02, or 0.2m/s.
So we add that to our velocity giving us 50.2m/s and start all over again.
The main difficulty with this approach is getting to and from stationary, as if your velocity is 0, all kinds of things go horribly wrong with the calcs, but given that you are doing drag racing, you can probably just script the start to give the car a small initial velocity, then then the simulation take over from there.
A further complication of the timestep method is if you cant rely on fixed lengths of time between your calcuations, then you need some method of keeping track of how much actually passed between frames, and putting that value into the equations. Again, I dont know if javascript in max can do this.
Anyway, enough rambling. Sounds like an interesting project, good luck with it.
If memory serves, the passenger byte works like the flag fields in SPR/MPR files. ie. its a bitfield with each bit representing a seat, so each seat has a value of 1, 2, 4, or 8 etc. and they are added together to give a single value.
Coo, some old skool threads there. Needless to say, I havent done a thing on working out .set formats for a long while. Still, its straightforward enough with a hex editor, I'm sure it wont take a man of your talents long
Ahahhahahaahhah.
Gentleman, start your flamethrowers.
Gentleman, start your flamethrowers.
NOOOOOOOOOOOOOOOOOOOOOOOOOOooooooooooooooooooooo!!!
*dies*
One of the things that visiting professor Todd Wasson has often said, is that real tyres do not have much significant grip drop-off after the peak. Far less than people really expect. So this behaviour isnt really that suprising.
Also bear in mind the effect of brake balance. Lets say for the sake of argument that a locked tyre generates 95% of the force of a perfectly threshold braked tyre.
When you lock up all 4 wheels, they will each generate 95% grip and your overall braking force will be 95% of maximum.
Now lets say you try and threshold brake. If you are using a typical kind of setup, your brake balance will be a bit forward, and your fronts will be runnning at a higher slip ration to the rears.
So maybe you get 99% of theoretical maximum on the fronts, but the rears are probably only generating 70-80% of their theoretical maximum.
Now obviously the load on the fronts is probably double that of the rears, so the effect of this is not as dramatic is it sounds but it probably brings the average force back down to the same sort of range as the locked tyres.
Also bear in mind the effect of brake balance. Lets say for the sake of argument that a locked tyre generates 95% of the force of a perfectly threshold braked tyre.
When you lock up all 4 wheels, they will each generate 95% grip and your overall braking force will be 95% of maximum.
Now lets say you try and threshold brake. If you are using a typical kind of setup, your brake balance will be a bit forward, and your fronts will be runnning at a higher slip ration to the rears.
So maybe you get 99% of theoretical maximum on the fronts, but the rears are probably only generating 70-80% of their theoretical maximum.
Now obviously the load on the fronts is probably double that of the rears, so the effect of this is not as dramatic is it sounds but it probably brings the average force back down to the same sort of range as the locked tyres.
Oh, do be quiet.
Well done for putting this together, I had the same kind of idea a while back but never got around to doing anything about it. Its a really nice, easy to use little program.
I'm sure you've got your own list of features you'd like to see implemented but here are a couple of ideas to add to it if they arent already there:
1. Import background image, with scale and move capability. That way people can import aerial maps and trace over.
2. Option to place arcs, not just beziers. Beziers are nice, but race tracks tend to have a high proportion of constant radius turns, which can be a bit of a faff to replicate with bezier.
Thats it, keep up the good work.
I'm sure you've got your own list of features you'd like to see implemented but here are a couple of ideas to add to it if they arent already there:
1. Import background image, with scale and move capability. That way people can import aerial maps and trace over.
2. Option to place arcs, not just beziers. Beziers are nice, but race tracks tend to have a high proportion of constant radius turns, which can be a bit of a faff to replicate with bezier.
Thats it, keep up the good work.
Yeah, sorry I misunderstood what you meant. My mental image of splines (few points, big curves) didnt fit with my mental image of lookup tables, but I see what you mean now.
I mean, its worth saying that interpolated look-up tables arent necessarily unrealistic, in this example they are probably more realistic. And they're probably faster than an equation as well. They just seem to lack elegance, and adaptability.
I mean, its worth saying that interpolated look-up tables arent necessarily unrealistic, in this example they are probably more realistic. And they're probably faster than an equation as well. They just seem to lack elegance, and adaptability.
Haha, no, nothing so elegant. Its just a huge text lookup tables with values about every 50 rpm. Not sure what form of interpolation is used between the values though.
Nah, what he means is that if you look at a torque curve for a real engine, it can be a broadly arbitrary shape with an irregular pattern to it.
The torque curve for LFS cars is generated from an equation using a few variables as input (those variables we play with in LFSTweak). This is a very flexible system as it allows quick and easy generation of new engine types, but the curves themselves are quite simple and mathematical in appearance. The current equation doesnt really allow for complex torque curves and so lacks some realism.
Other sims basically use a look-up table with a values of torque for each level of RPM, and the engine interpolates between them. Which is potentially more realistic, but isnt flexible or quick to alter.
Perhaps LFS could get the best of both worlds by keeping the equation driven system, but adding an optional 'offset' lookup table, so that values could be manually tweaked away from the equation results through the lookup table.
Then you could still use the equation system for flexibility and speed, and then in final tweaking, use the lookup table to offset the values nearer to realistic values, and add little details like where engines change cams and that sort of thing.
The torque curve for LFS cars is generated from an equation using a few variables as input (those variables we play with in LFSTweak). This is a very flexible system as it allows quick and easy generation of new engine types, but the curves themselves are quite simple and mathematical in appearance. The current equation doesnt really allow for complex torque curves and so lacks some realism.
Other sims basically use a look-up table with a values of torque for each level of RPM, and the engine interpolates between them. Which is potentially more realistic, but isnt flexible or quick to alter.
Perhaps LFS could get the best of both worlds by keeping the equation driven system, but adding an optional 'offset' lookup table, so that values could be manually tweaked away from the equation results through the lookup table.
Then you could still use the equation system for flexibility and speed, and then in final tweaking, use the lookup table to offset the values nearer to realistic values, and add little details like where engines change cams and that sort of thing.
If someone from FILSCA could give us some technical details about the format of the information in your database, and how the scripts would need to interact, I'm sure the LFS community could rustle something up very quickly.
Now I presume like most community type websites these days you are running a PHP/mySQL combo, and you have an established database schema for storing leagues and race results. If we can get access to that information then it should be straighforward to modify existing race result scripts to re-format the race-info to match the FILSCA database schema.
Now I presume like most community type websites these days you are running a PHP/mySQL combo, and you have an established database schema for storing leagues and race results. If we can get access to that information then it should be straighforward to modify existing race result scripts to re-format the race-info to match the FILSCA database schema.
I do miss the avatars. They are nice little personal identifiers and make it quite easy to recognise the participants in thread at a glance.
Definite no to images in sigs though, they always look crap.
Definite no to images in sigs though, they always look crap.
FGED GREDG RDFGDR GSFDG