Re: F1 22 UDP Specification

P4st3l1ak
Seasoned Ace
3 years ago
@chuschus
I see what you mean.

You could, possibly, do that based on allocation selected before FP1 and derive available tyres based on tyre damage from UDP.
Allocation is known, you have six scenarios (3 for normal races, 3 for races with sprints) which could be hard-coded. And based on tyre damage UDP, it could figure out what compound and how many are still available. Then it might be able to select right one for next pit stop.

I am curious: do you store past sessions somewhere and load that data up when you restart your wheel?
chuschus
3 years ago
@P4st3l1ak
No, it's not stored. That's the cause it would be great to have it in car status packet o at least in car setup. The fp1 could be done one day and the race another one.
The wheel can be used by multiple users, so it doesn't store that data.
P4st3l1ak
Seasoned Ace
3 years ago
@chuschus
I understand your case and it's what I assumed as well.
But you don't want to inflate packets to unreasonable size so CM may choose what info is stored in them.
chuschus
3 years ago
@P4st3l1ak
Yes, maybe it would be possible to put it in the TyreStintHistoryData from the Session History Packet, it would be 3 bytes/second/driver, or it could use bit encoding using 1 byte/sec/driver .
I don't see any other way to implement the commutator wheels.

Forum Discussion