Look what the cat hacked in - s02eo2

While I have not played r3e myself, I've been told that their netcode is just about the best one on the sim scene. Apparently they use a p2p method, so that 2 racers close together actually send data directly, as opposed to sending them to the server, and than back again. This effectively cuts the response time by half.

 

I know the topic of brakes and brake heat was banded around quite a lot in previous weeks but seems to have gone cold of late (no pun intended).

Is brake heat / warmup / cooldown / fading / magicpixies going to be in V1.3 or is that for a later time? Also, will there be brake heat output for python apps so that we can monitor the heat?

Thanks.

 

As Stefano said and it's not really obvious to people, brakes fading is much more complicated. Some road cars will not make more than 3 laps. Imagine the reaction of some users ( personally I would ready like this to be implemented )

 

But surely its no more of an issue of a road car now at say Silverstone GP with road tyres? You can't do more than 2 laps without the tyres overheating, but I don't hear the complaints...?

 

Also most cars with street tyres when pushed in a race track will lose grip fast (tyre wear) within a couple of laps. So is not like people race for too long with street tyres. Some street cars that have semislicks will drop as well in about 5 laps. Brake fade/temps can be important for both street and race cars, and maybe we won't get so many 'impossible' lap times, even during an online race, and people could catch up with them, especially me

Also in the first live stream of s02 I heard the mention to water simulation, so this brings into play a car cooling system, so when the car is colder the engine is less efficient, and then problems as well when the car is too hot. So performs better with a stable warm temperature. But depends on the car, since there's also oil and fan cooling with heat sinks (this one more for older cars, but oil is also present in a car with water cooling)).

 

Sliding scale from 'try to reproduce the most recent knowledge of what the other player's doing' to 'use the other player's driving style to motivate an AI driver' - at its most basic you'd just have the other driver's car moving from point to point as their client announces where they're driving (which would jump around a lot on a bad connection). Then a bit more complicated is using the time the packet took to arrive to predict they'll have driven forward some amount since the packet was sent, and show that position. Which will do pretty much what AC does, when a car lag spikes they shoot off in a straight line and then when the next packet shows up a half second later and contradicts it, their position is fixed. You can predict slightly in advance of the present, and move the car from its current position towards to that future spot, and get a smoother result (but introduce more difference between their actual and shown position). You can instead of predicting a straight line use an AI to drive their car forward the 200ms or whatever interval. Or go to the recent Forza model, and just record the player's driving style and don't have any 'real' interaction - their car would behave as naturally as the AI can manage, but not be showing anything specific. No warping, but no connection.

The problem with variable ping in the 'predict forward' model is that the predictions change depending on the ping - eg. if they're moving 50m/s at a 0.1 second ping you're predicting 5m ahead - if they're a 0.2 second ping, you're predicting 10m ahead from a reported spot 5m earlier on the track. If the player starts decelerating at 1G, then 5m ahead over 0.1s is off by 5cm, assuming you drove farther than you did. But critically, 10m ahead over 0.2s is off by 20cm - so if this change in ping time happened during a braking zone, they would have to be warped 15cm forwards to compensate (and then 15cm back if their ping drops again).

You can add detail to the prediction, eg. send the current pedal/wheel positions and use that to guess how far the car will go more precisely, but it's never going to be 100% correct - and in cases where it's biased (as above being decelerating means it predicted too far forward), a change in ping means a change in the amount of bias vs. the real position.

Applying smoothing to the position leads to 'rubber banding' which can only hide so much of the underlying prediction problem.
Applying 'real AI' is heavy on the CPU because it doesn't just have to calculate the AI one frame at a time, it has to calculate the entire set of decisions over the course of the ping time (250ms = 15 frames, or maybe 100 physics steps) or use some method to feed the difference in predicted vs. actual position (in the past) into its future decisionmaking process to try to make the two match up, which is tricky.

 

Hmm. So we get a sound telling us we can't downshift?? Is this how it works on this cars in real life?? Do they have this kind of protection built in??

Because if not, we should just have the engine being damaged and not this...

 

I'm pretty sure it just wont downshift if your asking it to do so when it may cause damage. Don't think there will be any sounds.

 

Most paddle shifters yes - the fancy ones will shift when the gear is 'ready', the annoying ones will just ignore your button push.

 

a) No news on the physical implementation lately, except that the glowing brakes are working like a charm and are looking very good.
b) No news on if it would be in 1.3 either. Maybe a good question for the next Q/A.
c) If not Kunos, then someone else here will make an app for it, thats nearly sure, because why having brake temps when not knowing about it?

 

If the real cars prevent the wrong downshifting it's good that they simulate it. If it's just to prevent damage for bad drivers, that's a bad approach I believe

 

That makes sense, however at the moment we still don't have inner/mid/outer tyre temps outputted to apps, just the one single value. So I wasn't going to assume that brake temps would be either.

 

(curve is from a real tyre)

Could you please explain on this image! what would DY0, DY1 ,DY2 and NL_LS_REF_KG be in the next patch ?

I have my little idea, but i don't like conspiracy theories

 

@Ben Lee: Thats true, python devs can only work with what they have access to. So, lets hope it will be there.

 

you realize that that graph is doing the opposite of what people are asking for? That graph is actually indicating the tyre has MORE grip than expected at high load. With a linear load sensitivity like we have now.. if the slope of the first 2 readings is used.. at 6000N you'd end up with roughly 0.5mu .. much less than the 1.2mu reported by the graph.. invalidating the whole "too much grip at high loads" soap opera.
What people are asking the exact opposite of that curve... one that starts slow and end up steeper at high loads.

 

Yes, which brings me to the next point:

Those mu values can't be used on AC at all ... they would feel extremly grippy! but still they are reaslistic values... i don't know why ?

 

Well, it's just a matter of which problem you accept. If you tune the tire to the 1st and last datapoints, in order to keep the entire operating envelope within reason, it makes the midrange too grippy (which makes fast corners too fast). I believe that's what modders are ending up doing, since the alternative means you fit the first couple points and then when you go over bumps mu can drop well below a plausible number (linear dropoff of mu means there's a point where you start getting less force than with lower tire load, and a point beyond that where mu drops to 0 and you get no grip at all if the tire's loaded too much)

 

because perhaps tyre tests can't be trusted blindly without knowing:

1) who did the measurement and why (the "why" element is more important than you might think)
2) what machine was used for the test
3) what surface the test was run on
4) what speed the test was run on

The very same tyre, measured by different machines gives very different results.. can't trust one data.. need to go through many different source and find the common trend.

To answer your previous question, DY2 is a quadratic factor for load sensitivity that kicks in once the load exceeds NL_LS_REF_KG, so it is possible to have a linear range and a non linear range .. it is designed to have the curve fall off quickly (as per soap opera plot ) but it could also be used to have the curve reducing the slope with load to reproduce the data you have linked.

Finally.. the data is not really that grippy..it's quite aligned with the levels we have in AC for a high performance tyre.

 

so perhaps we should rename the soap opera "Too Much Grip At Medium Level Load Cause The Modder Choose The Wrong Reference Points"

 

Works for me, I'm just interested in the problem from a mathematical perspective as usual, I don't look at any of the real data.