As I didn't find it in the list or in this sub-forum, so here it is:
1. To make time recording more accurate, like to measure time in not hundreds of a second but in thousands, because it happens often that in qualifying, times of few drivers are the same.
2. Setup sorting, for example each car in setup folder would have it's separate folder and in each folder you would be able to make more folders, just to organise your setups, people could have possibility to sort their setups by tracks, leagues and etc.
So it's just my 50 Cent... Oh snap, it should be 2 cents

+1, nothing more to add.

+2

These are very nice suggestions.

Increasing timing precision to thousandths of seconds has been discussed a bit before. The problem is that to have an accurate position every 1000th of a second the physics loop would have to run at 1000Hz (an increase of 10x the current rate). This would further increase the burden on the CPU, which is already fairly heavy. The increase in precision (which would definitely be useful in certain scenarios especially) is desirable, but not if it comes at the expense of requiring much more powerful PCs to run LFS.

Quote from amp88 :

Increasing timing precision to thousandths of seconds has been discussed a bit before. The problem is that to have an accurate position every 1000th of a second the physics loop would have to run at 1000Hz (an increase of 10x the current rate). This would further increase the burden on the CPU, which is already fairly heavy. The increase in precision (which would definitely be useful in certain scenarios especially) is desirable, but not if it comes at the expense of requiring much more powerful PCs to run LFS.

Well, I found that iRacing's physics engine rate is 360Hz and it still can count time in thousands of second.

Quote from iFastLT :

Well, I found that iRacing's physics engine rate is 360Hz and it still can count time in thousands of second.

There was a reason I added the word "accurate" and made it bold so as to draw attention to it. If the physics engine is running at 360Hz but the timing is claiming to be precise to 1000Hz then there has to be some sort of interpolation going on. That is to say that the engine is doing something along the lines of saying "the last time I calculated an accurate speed of the car using the physics engine I knew it was moving at speed x in direction y with an acceleration of z. Therefore I calculate its position to be A, despite the fact I can not know with certainty this is the new position since I have not taking into account things that could have changed the speed or acceleration of the car (like bumps in the road, kerbs etc)".

Quote from amp88 :

... is desirable, but not if it comes at the expense of requiring much more powerful PCs to run LFS.

You forget about network capacity. It would need like 2Mbps upload speed to send all the info at such low rate

@amp88 - You are both right, and wrong with the accuracy issues. You can use a little linear algebra to figure out the exact time from StartTime, to EndTime (in LFS's case X.01 and X.02) that a car crossed a split/finish line. By knowing the position they were at during time (X.01) and the position they are now at during time (X.02) just calculate a where it crosses the plane/line of an important timing section; split / finish.

About the accuracy, you are right you won't be 100% accurate, but you likely will be more accurate than the way it is currently done, which is LFS checking the position of the car at time (X.01) and time (X.02) but NOT checking _where_ during that time the car actually crossed the finish line. You are correct, this will lose some accuracy because this interpolated time value will not include acceleration changes over that small time slice. But, it could be argued that even without that, it is still more accurate since a car that finished immediately before X.02 could tie with a car that finished immediately after X.01.

I don't know if what I said made sense, but I hope it did. I am not pulling stuff from no where, and I actually do understand what is going on. Just a few lines of code would be required for the more accurate, (in my opinion, even lacking the acceleration changes), timer that would interpolate the position of the car until the moment it crossed the start/finish line or a split for that matter.

Quote from blackbird04217 :

...

See, the thing is I think a more accurate reading of a less precise value is better than a less accurate reading of a more precise value. That is, I am happier to have a 100% accurate reading (100% accurate to LFS' physics engine, that is) to 2 decimal places than a 99.9% accurate reading to 3 decimal places. It may be possible to make a more accurate version than the current version by adding a little complexity to the calculations as you suggest, but if you present the user with a display that is precise to 3 decimal places they would assume (probably rightly so) that the underlying model provides an accurate 3 decimal value. Unless the underlying model is actually running at 1000Hz you'll never have a truly 100% accurate value (100% accurate again meaning accurate to the LFS physics engine).

I kinda understand where your going, although I do not agree that it is any less accurate- It is more accurate, and not just in precision, even based on a 100mhz engine.

I go back to this argument, though worded slightly different;

Car A, crosses the finish line at X.011 (Real-Time).
Car B, crosses the finish line at X.019 (Real-Time).

Car A finished before Car B, and this would be 100% accurate.

A simulation engine, running at 100mhz, would detect this 1 of 2 ways, either both cars get a time of X.01 or both cars get a time of X.02. It depends on how the simulation is checking previous versus next positions... However, for sake of argument we will pretend this engine is set up for X.01, truncating the remaining time.

Each car now finished at X.01. (Simulated Time). With my segment check you can get the exact time the user crossed the line, not only more precise. The only accuracy you are 'losing' is due to acceleration / braking forces within that 0.01s that occurred. You could even include this with an avg acceleration over the frame - which would make it perfect to the engine capabilities.

My point here, is that how is considering both cars to be X.01 more accurate than detecting the exact time X.011 and X.019? As long as the engine is _always_ doing the same thing, and it computes the same time every where, which it should do automatically - then I do not understand how truncating each time to 0.01 is more accurate in any regards.

What I do understand is the slight loss of accuracy from not interpolating the acceleration. This is even possible with a little more effort and thought, though I don't think that is needed to achieve higher accuracy than we currently have. I do agree that I do not want some randomly created, higher precision values. But the calculation would always run the same, for everyone, and would be part of the engine. I would like to hear why your thinking that 0.01 is more accurate than (a correct implementation of) the interpolated time calculation.

Afterall, if the simulation engine is running at 100mhz, the car/object will move linearly during each given time step.

Quote from blackbird04217 :

I would like to hear why your thinking that 0.01 is more accurate than (a correct implementation of) the interpolated time calculation.

Well, I actually agree with you that some interpolation could give a more accurate solution than the current 2 decimal places solution (as I said above). What I take issue with is the attempt to add precision using calculated values that may or may not be accurate.

Quote from blackbird04217 :

The only accuracy you are 'losing' is due to acceleration / braking forces within that 0.01s that occurred. You could even include this with an avg acceleration over the frame - which would make it perfect to the engine capabilities.

Afterall, if the simulation engine is running at 100mhz, the car/object will move linearly during each given time step.

This is the problem for me. We're both agreed there is a degree of uncertainty involved here. However well you can try and cover for that uncertainty you are never going to be able to eliminate it. Unless you can eliminate it you should not claim to be able to provide accurate values of higher precision. I understand the degree of uncertainty is very slight in practical terms (which is why I acknowledge that your proposed solution would probably provide a more accurate value than the current solution), but I don't personally see the need to move to a solution that we can all acknowledge is of questionable accuracy when we currently have a solution that's of 100% accuracy at a lower precision.

LFS' general physics run at 100Hz, the tire model runs at 2000Hz. Guess it doesn't really matter though.

You could introduce higher fidelity time keeping, it doesn't have to be synced with the physics engine . It's not like the cars stop moving between increments or something, it's just that new forces are introduced to it every 1/100th of a second. Let's call it "mathematical inertia"

Quote from Ball Bearing Turbo :

LFS' general physics run at 100Hz, the tire model runs at 2000Hz. Guess it doesn't really matter though.

Yeah, because if a part that runs at 100Hz can have an effect on the speed or state of the car (e.g. the collision detection or the way the car/suspension interacts with the road surface) then it will limit the precision of the timing to 100Hz even if other aspects run with higher frequency.

Quote from amp88 :

If the physics engine is running at 360Hz but the timing is claiming to be precise to 1000Hz then there has to be some sort of interpolation going on.

This is where you're going wrong, that's not a true statement at all.

Quote from Ball Bearing Turbo :

This is where you're going wrong, that's not a true statement at all.

Care to elaborate?

The physics engine running at 360Hz means that 360 times a second the accurate state of the car (including speed, direction, acceleration) is calculated. Between these calculations the car may move to a new location on the track. At the new location on the track the road surface may be different. If, for example, at one calculation the road is completely flat and at the next calculation the front tyres are now sitting on an incline of a couple of degrees the state of the car has changed (since it's now starting to travel uphill). If you take timing from between these 2 states (travelling on flat and travelling uphill) it ignores the fact the car has transitioned because it knows nothing of that transition.

Quote from amp88 :

Yeah, because if a part that runs at 100Hz can have an effect on the speed or state of the car (e.g. the collision detection or the way the car/suspension interacts with the road surface) then it will limit the precision of the timing to 100Hz even if other aspects run with higher frequency.

It will only limit the precision of said 100hz calculations, which are not necessarily in bed with timing & positional updates.

Here's a backwards analogy but you get the idea: even if your graphics card can't draw a decent framerate - your "visual accuracy" will drop but things are still happening in the background.

edit: That's fine, I don't disagree with you that it would *ideal* to run at the same frequency, but for the sake of 1 360th of a second... who gives a toot if you're on a 1 degree incline now, that 360th of a second isn't enough time for any non-cataclysmic force to have any appreciable effect on the mass of a speeding car - therefore decoupling timing from new physics being applied to the car is a totally reasonable, and probably more accurate approach than simply truncating values.

Quote from Ball Bearing Turbo :

edit: That's fine, I don't disagree with you that it would *ideal* to run at the same frequency, but for the sake of 1 360th of a second... who gives a toot if you're on a 1 degree incline now, that 360th of a second isn't enough time for any non-cataclysmic force to have any appreciable effect on the mass of a speeding car - therefore decoupling timing from new physics being applied to the car is a totally reasonable, and probably more accurate approach than simply truncating values.

Argh. So you make a statement saying I'm wrong then you're effectively agreeing with me. You say the change is not appreciable but you're agreeing there is a change. This is EXACTLY what I said above. You would probably get an increase in accuracy of values overall but you're moving from an arguably perfect solution at lower precision to a flawed system at higher precision.

No, you said there had to be interpolation - an active attempt at getting something that's not there. The circumstance I described is not that, it's just letting math run it's course

interpolation:
To estimate a value of (a function or series) between two known values.

That would not be happening, and it would be a waste of time to do it (no pun intented)

Quote from Ball Bearing Turbo :

No, you said there had to be interpolation - an active attempt at getting something that's not there. The circumstance I described is not that, it's just letting math run it's course

interpolation:
To estimate a value of (a function or series) between two known values.

That would not be happening, and it would be a waste of time to do it (no pun intented)

OK. Which of the following statements do you agree with (irrespective of the frequency of the physics loop in comparison to the timing loop).

• The accurate speed, direction and acceleration of the car can only be obtained during an iteration of the physics loop.
  
• The speed, direction and acceleration of the car between iterations of the physics loop cannot accurately be known.
  
• Events which occur between iterations of the physics loop can effect the speed, direction and/or acceleration of the vehicle.
  

Quote from amp88 :

OK. Which of the following statements do you agree with (irrespective of the frequency of the physics loop in comparison to the timing loop).

• The accurate speed, direction and acceleration of the car can only be obtained during an iteration of the physics loop.
  

That's looking at it like you have infinite sample opportunities. We don't which is the whole point of this conversation. Your statement is self cancelling. It should read "the current (for this 360th/sec) direction and acceleration of the car can only be obtained during an iteration of the physics loop".

• Quote :

  The speed, direction and acceleration of the car between iterations of the physics loop cannot accurately be known.
  
  

It is known as well as it can be known - as far as we're concerned, it's the same as it was until it's recalculated.

• Quote :

  Events which occur between iterations of the physics loop can effect the speed, direction and/or acceleration of the vehicle.
  
  

If you have things running at higher resolution, sure, but it doesn't matter to us until your lower res loop uses that information to update the situation.

Quote from Ball Bearing Turbo :

That's looking at it like you have infinite sample opportunities. We don't which is the whole point of this conversation. Your statement is self cancelling. It should read "the current (for this 360th/sec) direction and acceleration of the car can only be obtained during an iteration of the physics loop".

I would argue that given my previous posts and the wording of the statement (i.e. "during an iteration") makes it clear that I know there is a finite maximum frequency with which the physics loop can run.

Quote from Ball Bearing Turbo :

It is known as well as it can be known - as far as we're concerned, it's the same as it was until it's recalculated.

Yes, so when the state of the car (including speed, direction and acceleration) is calculated for the current iteration of the physics loop that state is assumed constant for the time taken until the next iteration (the next 1/360th of a second, for instance). That is why this is the limiting factor on the precision of the timing you can accurately provide. If you assume nothing that comes between iterations of the physics loop can change the state of the vehicle and use that as a basis for providing more precise timing you are providing a false sense of precision. In the case of LFS this precision is 0.01 seconds (the period associated with a frequency of 100Hz), in the case of iRacing it's 0.00278 seconds (the period associated with a frequency of 360Hz). Providing more precision than this is inherently inaccurate.

Quote from Ball Bearing Turbo :

If you have things running at higher resolution, sure, but it doesn't matter to us until your lower res loop uses that information to update the situation.

This demonstrates my problem but my view of the problem does not explicitly require a higher resolution aspect of the system to be running (the higher resolution just makes it a bit more obvious). When we calculate the state of the car and assume it's accurate until the next iteration we are explicitly ignoring anything that may have happened between now and then if we had infinite sample opportunities. We are therefore limited in precision to the resolution of the slowest part of the system which handles the state of the car (in the case of LFS the 100Hz look and in the case of iRacing presumably the 360Hz physics loop).

If I were to develop a sim and say its physics loop ran at 1Hz but my timing was precise to 1/10,000th of a second you would think I was talking out of my rear orifice. You would be correct. The case is the same here but with a less extreme disparity.

edit: See attached diagram.

Quote from amp88 :

I would argue that given my previous posts and the wording of the statement (i.e. "during an iteration") makes it clear that I know there is a finite maximum frequency with which the physics loop can run.

Oh I know you're well aware of that, I didn't mean to sound patronising.

Quote :

If you assume nothing that comes between iterations of the physics loop can change the state of the vehicle and use that as a basis for providing more precise timing you are providing a false sense of precision.

Not really.

Quote :

Providing more precision than this is inherently inaccurate.

No it's not, it's only *possibly* inaccurate, and the relatively low possibility of that inaccuracy is overshadowed by the benefit it would provide in situations that really matter. Surely you could come up with extreme situations to show me that it could be inaccurate, but in normal racing conditions it just doesn't matter much, if at all.

Quote :

When we calculate the state of the car and assume it's accurate until the next iteration we are explicitly ignoring anything that may have happened between now and then if we had infinite sample opportunities.

But your logic is based on something totally irrelevant. We DON'T have infinite samples. That's why I said that before - not because I didn't think you understood that, but because you're basing your argument on pie in the sky. You can't ignore something that "may have happened" when it's an impossibility for it to mathematically happen given the limiting factors of what the real situation is.

Quote :

We are therefore limited in precision to the resolution of the slowest part of the system which handles the state of the car (in the case of LFS the 100Hz look and in the case of iRacing presumably the 360Hz physics loop).

iRacing disagrees with you . I understand your argument. But picture two cars racing (almost) side by side on the home straight. It's far more beneficial to have more accurate timing than to worry if a 2000km/h gust of wind came from the depths of hell towards one of the cars and alterered it's projected trajectory enough to matter in that (very) tiny fraction of a second.

Quote from Ball Bearing Turbo :

Not really.

If you're going to single out a point I've made and say it's false could you please explain why you think it's false?

Quote from Ball Bearing Turbo :

No it's not, it's only *possibly* inaccurate, and the possibility of that inaccuracy is overshadowed by the benefit it would provide in situations that really matter.

Well, that's a semantic argument. If a system has a possibility of providing an inaccurate result (which you agree with) then you cannot say with certainty any of the results produced within that system are accurate, can you (since we don't have the capacity to determine which are accurate and which are inaccurate)?

Quote from Ball Bearing Turbo :

But your logic is based on something totally irrelevant. We DON'T have inifite samples. That's why I said that before - not because I didn't think you understood that, but because you're basing your argument on pie in the sky. You can't ignore something that "may have happened" when it's an impossibility for it to mathematically happen given the limiting factors of what the real situation is.

That's why we even have the idea of precision in any measuring device we create or possess. Speedometers, tachometers, rulers, clocks etc all provide a finite level of precision. In the case of LFS the available precision of the timing is 0.01 seconds. I don't see how you can disagree with this fairly fundamental concept. Please don't just say "not really" or "this is where you're wrong". Please provide a logical argument.

Quote from Ball Bearing Turbo :

iRacing disagrees with you . I understand your argument. But picture two cars racing (almost) side by side on the home straight. It's far more beneficial to have more accurate timing than to worry if a 2000km/h gust of wind came from the depths of hell towards one of the cars and alterered it's projected trajectory enough to matter in that (very) tiny fraction of a second.

Argh. I understand that with a system that uses interpolation (and that's what's happening if you have 360Hz physics and 0.001 second precision!) may provide more accurate values overall than sticking to the precision determined by the slowest part of the system, but I'm not arguing that point. I said it right off the bat in my third post in this thread. What I'm arguing is that the system is inherently inaccurate. The fact that something like a 2000kph wind could come in and make the timing inaccurate is what I'm saying is the problem. I don't personally mind (as though what I care about effects what Scawen may choose to implement) if some interpolation is used to provide the illusion of millisecond precision, I'm just saying that such a system would provide inherently inaccurate results because they depend on interpolation.

Please, if you respond to me don't just say "you're wrong" or "not really" or claim what I'm saying is "pie in the sky". Make reasonable arguments.

Quote from amp88 :

If you're going to single out a point I've made and say it's false could you please explain why you think it's false?

Sorry I didn't expand; the point was covered in the very next paragraph I wrote as to why. Thought you'd see the flow

Quote :

Well, that's a semantic argument. If a system has a possibility of providing an inaccurate result (which you agree with) then you cannot say with certainty any of the results produced within that system are accurate, can you (since we don't have the capacity to determine which are accurate and which are inaccurate)?

With two cars approaching a finish line, the likelyhood of something signficant enough to affect either vehicle enough to be remotely relevant happening inside of 1/360th of a second is extremely low.

Low enough that I can say with practical certainty that under such circumstances, two cars finishing with times of 1:40:01.071 and 1:40:01.079 is, for all intents and relevant purposes, more accurate that stating that both finished with times of 1:40:01.07.

The situation in my explanation is in fact likely to be less prone to error than truncating at 1/100th simply because "that's all we can measure based on the lowest common denominator". You're more likely to have a higher degree of accuracy by letting the timer continue between physical updates than you are by purposely limiting it.

Quote :

... may provide more accurate values overall than sticking to the precision determined by the slowest part of the system, but I'm not arguing that point ...... what I'm arguing is that the system is inherently inaccurate.

So the inherently inaccurate system may provide more accurate values overall. Gotcha!
(lol, I know what you're saying I just had to do it)

Quote :

The fact that something like a 2000kph wind could come in and make the timing inaccurate is what I'm saying is the problem.

You can say it's a problem all you want, it's not a problem. It's just a very, very minor compromise for a much bigger benefit.

Quote :

Please, if you respond to me don't just say "you're wrong" or "not really" or claim what I'm saying is "pie in the sky". Make reasonable arguments.

Every time I've used such brevities, I've followed up with why in the same post, and generally immediately after.

Look:


1) Within the realm of the accepted limitations, yes, limiting timing to the resolution of the physics engine will make the timing result 100% accurate to the physics engine no matter what, but it's a very strange assertion to define that as "inherantly accurate"

2) Allowing the timer to run independantly will provide results that are, in fact, more accurate in all but the most ludicrous circumstances. I don't care if you call it inherent accuracy or not, it's more accurate in practical circumstances that anyone gives two poops about.

Would you agree that we're actually in agreement?