hm yeah. Though i fear that would break RAF compatibility. There are only 3 unused bytes in the dymanic wheel block, and I can imagine this value should be a float.
In other words, not a simple fix.
OR if it doesn't need to be very precise, a short could do and then it would be comptible. I guess I'll mail scawen the url to these posts
i could add graphs for those values. But imo that's hard to read as well. You'd get 12 additional graphs for just the 3 forces per wheel. How can you compare that nicely? You can't put 12 graphs underneath one another. And drawing more than 1 graph in an area will make things hard to read as well.
That's why i thought it might be nice to come up with an all-in-one view for forces and temperatures. But as long as there are no grip values to compare the forces to, it's all kinda meaningless.
So wsinda's proposal makes the most practical sense to me atm. Though I don't know how practically feasible this is atm.
In the RAF format definition, the block sizes are not fixed; the block sizes are given in the header. It ought to be possible to append data to the dynamic wheel block without breaking existing apps (provided they were programmed correctly).
There are 3 forces (lat, long, load), so that's 1 byte for each force. Let that encode for its colour in the forces view inside LFS (e.g. 0x00 = green, 0x80 = yellow, 0xff = red).
There is a problem with the RAF file that you can download. This RAF file has a sample frequency of 10Hz, against 100Hz for the standard RAF files from LFS. (The RAF file was probably condensed to save download time in the LFSW Analyser.)
When you load this file into another analyser, the analyser reads less samples, and will calculate a lap time that is 1/10th of the actual time. One effect is weird values for Longitudinal G force (10 times too high).
(The real cause is the fact that the sample frequency is not stated in the RAF file. Existing analysers have 100Hz hard-wired.)
Possible solutions:
Add the frequency to the RAF format.
Download the full RAF file (if it is still available).
not on our server. We only store the 10hz versions.
but yes, I guess the rate should be stored. Plenty of room in the header for that though.
btw, we store GForces in the RAF now. Only at one byte though, so it's a bit grainy, but it's there.
We'll update the RAF format specs with patch Z, but here's the updated part for gforces :
DATA BLOCKS : 192 bytes (B) every Nth of a second
1 float 0 throttle : 0 to 1 1 float 4 brake : 0 to 1 1 float 8 input steer : radians 1 float 12 clutch : 0 to 1 1 float 16 handbrake : 0 to 1 1 byte 20 gear : 0=R, 1=N, 2=first gear 1 char 21 lateral G * 20 : -120 to 120 = -6 to 6 G 1 char 22 forward G * 20 : -120 to 120 = -6 to 6 G 1 char 23 upwards G * 20 : -120 to 120 = -6 to 6 G 1 float 24 speed : m/s ...etc
6 char 0 LFSRAF : do not read file if no match 1 byte 6 game version : ignore 1 byte 7 game revision : ignore 1 byte 8 RAF version (2) : do not read if increased 1 byte 9 update interval : ms (normally 10 / hlvc 100) 2 byte 10 0 : etc...
Additionally, a so called 'slip fraction' byte, for force colouring, has been added to the dynamic wheel info block :
snip.... 1 byte 28 air temperature : degrees C 1 byte 29 slip fraction : (0 to 255 - see below) snip...
Slip fraction ------------- This is the dynamic value of the current combined slip ratio relative to the combined slip ratio that would provide the greatest force.
0 to 254 - slip ratio increasing up to maximum force available 255 - slip ratio exceeds the maximum force slip ratio
I'm currently exporting all hotlaps again, so they will be updated with that info. Will take a day or so though.
Can anyone explain what this combined slip ratio means? Can I view it as the fraction of the "traction budget" that has been used? Or is it really a slip ratio, i.e. a ratio between the actual motion of the wheel and the motion of the car (and if so, how is it combined)?
I appologise if this has already been mentioned, (and appologise again if it already does it and i'm just being blind), but it would be good if the graphs could have a track position (ie distance) as well as time. Time makes it difficult to compare braking points and throttle positions because faster/slower drivers will reach the same points on the circuit at different times.
To clarify. Could we have the X-Axis have distance as an option for the Gear/Throttle/Brake/Speed graphs etc. Rather than time as it is currently.
Edit - Scrap that, I've just found the Sync button.
Just saw this now (tells how active I've been lately :shy - It's a great addition to LFSW, and finally nice to just hop in and do some quick comparisons.
That's search_glow that's causing the error. Search_glow is part of the windows live toolbar. If you google a bit for 'search glow' you'll find a lot of information on the topic including how to disable it.
Aha .. I had suspicion it was somthing along those lines, just thought odd as only happens after machine has been rebooted and its first thing loaded into adress bar.
Anyways was just thinking ....is it/would it possible to output temps of the tyres for IHA ?
Would be quite infomative to see where tyres take most punishment/wear.
