Isi please give us the option! Dont force it! Either option it, or get rid of it!

In short: making it an option is NOT an option...

Thank you! Someone finally saw the light

 

Yes making it optional of being optional is the correct option!

 

I have no information whatsoever about how for example direction prediction is actually done but I strongly believe it's not based on steering, throttle, brake, etc. data sent from server. Server side has the lowest lag of clients so wouldn't it be reasonable to do the main math there? And about brake etc. info sent to clients; if blocking the info would be allowed by server and client wants it then client software should not make that information available for plugins.

 

Well in this case it is easy. Like I summed up, I don't think it is a problem. In my opinion it really is fine as it is, and I would rather have the Dev's to spend time on other stuff then this

 

How would your client ("rFactor 2.exe") know when to rev up the remote opponents engine, if it wouldn´t know about throttle inputs, same for the braking and brake lights (if the car has them). And you want to see the steering wheel actually turning when you watch another opponent, don´t you?
About the math on the server, I don´t think so, becuase to run physics for only one car brings some CPUs to their knees already. Also, the lowest lag is on the actual client, it does the heavy lifting on the physics. I wouldn´t want physics lag of at least 20 ms to be added to latencies that are inherent in my equipment. The client sends the resulting vectors to the server along with user inputs. The server has to rely on and trust the network packets it receives, which is why i.e. cheating can never be truely prevented, because a cleverly manipulated client could forge the data. And the server needs to do predictions because of the network latency. And the best example that above must happen so or in a similar fashion, is a lagging/warping opponent. Revs are stuck, because there is no update on throttle input and the car is basically doing what it did when the last network packet was send to the server.
That´s how I think it works, I have no hard evidence to prove it, to be honest, but it makes sense, to me at least.

And since above does not work without sending information like throttle and brake to the server and from there to the opponents, it would not make sense to block it on the opponents client, because clever individuals could just sniff that information directly from the network packets.

Even if it is totally different, it still is a simulation of physics at work. Physics being what they are, one could also calculate throttle input from the revs and G-forces and other data. As long as we get information about the current physical state of the vehicle, no matter how it looks in detail, such reverse calculations would be possible.

 

It has nothing to do with at what meters he did this or what meter he did that, NOTHING to do with that at all. It has to do with much more advanced techniques, and not "brake started at 45 meters", "throttle started 1 meter after the apex" .

If you dont understand this concept, then thats ok, but you dont have to mock people about it.

Exactly

 

I like it.... get to see who is driving heel toe.