GT7 is compatible with motion rig ?

[F1Bernardo]

One thing that’s been on my mind is what’s the best proxy for tire wear: I assume it’d be related to temperature… everything that hurts tire life also increases their temperature. Can you guys test if a “kind on tires car” (BRZ 😂) has smaller peak temperatures under braking, cornering and so on…compared to a bad tire car (like the SLS? Or some other heavy FR)

 

[tarnheld]

Trying not to take away from the main thread here, but with your proxy and SRS, how much control do we have over bass shakers??
Currently, is it just engine rpm and gear change effects?

Do you think we will get kerb rumble effects?

Looking at the proxy code and the SRS API, there is not just RPM and gear change, but also lateral and angular acceleration and tire suspension movement sent over to SRS. The acceleration needs more work, the GT packet doen't contain acceleration but only velocity values, so the acceleration has to be calculated from velocity. Since acceleration is velocity change over time, it's not too hard to get to the acceleration values. The SRS API also expects to know if the tires are over track, rumble strips or off-track, that's something the GT packet doesn't give you. So there might be some effects supported by SRS that doesn't work with the current state.

One thing that’s been on my mind is what’s the best proxy for tire wear: I assume it’d be related to temperature… everything that hurts tire life also increases their temperature. Can you guys test if a “kind on tires car” (BRZ 😂) has smaller peak temperatures under braking, cornering and so on…compared to a bad tire car (like the SLS? Or some other heavy FR)

There is tire temp., but you can also extract tire spin by comparing wheel speed to vehicle speed -- if the tires are spinning much faster than the vehicle is moving, you can infer that the tire is spinning. This spinning will cause the tire temp. to go up, so i agree that the tire temp. is the main factor of tire wear in GT. My wild guess about tire wear is that it's directly related to tire temp and the type of tires. But we don't know the type of tires from the packet data, so some guesswork is still involved. But there is the chance that the increase in tire temp. is directly related to the types of tires -- that for RH tires the increase in temp. is slower than RS tires in such a way that a simple formular only looking at the temp over time will give you tire wear directly. Something like:

wear = wear + (current_temp - temp_threshold) * time

i.e. the wear is the accumulation of temperature that is over a certain temperature threshold over the time the temperature is acting on the tire. Would be worth a try -- if it would be that simple, a test would be to

• do a donut until the tire is worn out half, accumulate the temperature over this time span to get value A
• do some normal driving until the tire is worn out half, accumulate the temperature in the same way to get value B
• if A and B are the same, we have such a simple relationship
• do the same thing for a different type of tires, getting C and D
• if A and B are the same as C and D, the tire type doesn't matter and A,B,C and D can be called tire wear

 

[TR1T0N]

Some things i have noticed whilst reverse engineering the original Access software, Tire Suspension Travel in offset 0xC4 is listed a stroke rather than travel, im not sure if this has any effect on how we should parse it? the section within offset 0xD4 is used by the software and is accessed next to the suspension and wheel code which suggests it could be linked from what i can see it is two sections of 4 floats [fl,fr,rl,rr] though what it does is a mystery. As for the theory that there is another port for accessing extra telemetry based upon what i can see from the access code this does not exist or at least it was never revealed by PD or implemented by the access team. also theres a heap of vector and plane math which i do not possess the knowledge to follow or understand which im assuming they are using for processing to send back to their rigs.

 

[TheAdmiester]

I'm no fancy dashboard/UI designer, but I've been working on a quick and dirty app to suit one of my own use cases.

Currently I have an online database where I store all of my "average Joe takes the car around a track without dedicated practice" times, usually on the Nords, sometimes on other tracks. Last night I realised that because I can simply listen for a lap counter change in the game's packets, I can automate almost the entire process. I made a list of all of the cars' makes and names to link to the IDs that the packets display so that I don't have to populate the car fields myself.

Usually I would set a lap and put the details in a form manually to submit to my site, but now with the sim interface, I only have to manually specify the track that I was on - this pic shows the time completed in the game, my program on top of it having submitted the time, and the same time on my webpage:

 

[MCrisostomo]

However if a tool like this could be set up, having a real time leaderboard wouldn’t be really useful unless you join it with some text-to-speech to have like a race engineer keeping you up to date with some stuff (penalty ahead, guy behind setting better lap time, driver ahead loosing many position due to crash probably, flags…) and get something like crew chef

It would be a good function to the game. We have this in Codemaster's F1 games and there is a mod like this in rFactor. Some people told me some years ago that a Spotter mod in rFactor that are activates by voice command. You could call the spotter any time using your voice and asking for any information like lap time for example. Is possible to develop a PC application that recieve this informations and speak to the player?

Spotter mod for rFactor: https://www.racedepartment.com/downloads/spotter-plugin-v2-17-by-carlomaker-f1dave.50356/

 

[snimat]

I'm no fancy dashboard/UI designer, but I've been working on a quick and dirty app to suit one of my own use cases.

Currently I have an online database where I store all of my "average Joe takes the car around a track without dedicated practice" times, usually on the Nords, sometimes on other tracks. Last night I realised that because I can simply listen for a lap counter change in the game's packets, I can automate almost the entire process. I made a list of all of the cars' makes and names to link to the IDs that the packets display so that I don't have to populate the car fields myself.

Usually I would set a lap and put the details in a form manually to submit to my site, but now with the sim interface, I only have to manually specify the track that I was on - this pic shows the time completed in the game, my program on top of it having submitted the time, and the same time on my webpage:

View attachment 1179606

Can you open source that list of cars and ids? I would like to import into my own fork of @Bornhall s Python telemetry script. These are the changes.

I have added a section for tuning analysis and some metrics I need for improving my driving style.
For tuning analysis I am logging the max speed in a session. I can tune the transmission according to that max speed afterwards.
Also the body height in the metrics seems interesting. As for as I understand I can lower the body height as long as the minimum body height is > 0 for the session.

The other metrics are for clean breaking and throttling. I count the "ticks" that I throttle and brake at the same time and also the the ticks I do not use throttle and the brake at all.

 

[Stoobert]

It would be a good function to the game. We have this in Codemaster's F1 games and there is a mod like this in rFactor. Some people told me some years ago that a Spotter mod in rFactor that are activates by voice command. You could call the spotter any time using your voice and asking for any information like lap time for example. Is possible to develop a PC application that recieve this informations and speak to the player?

Spotter mod for rFactor: https://www.racedepartment.com/downloads/spotter-plugin-v2-17-by-carlomaker-f1dave.50356/

The problem is the data for other cars is not available in this packet, this would be sent over the wire presumably inside the HTTPS packets. Now, I severely doubt that Sony will let me MITM myself, but hey, you never know!

 

[RealJean42]

I wrote some little tools to capture and save data.
My goal is to be able to compare laps side by side and learn to improve lap times.
I used Nenkai's interface code to capture the data (thanks!)

You can find the code and Windows exe downloads here:
GT7Analyzer

Use as you please. I hope to improve it further....

Update:
Added some visualization (no comparison yet...)

 

[Hyurt]

It would be a good function to the game. We have this in Codemaster's F1 games and there is a mod like this in rFactor. Some people told me some years ago that a Spotter mod in rFactor that are activates by voice command. You could call the spotter any time using your voice and asking for any information like lap time for example. Is possible to develop a PC application that recieve this informations and speak to the player?

Spotter mod for rFactor: https://www.racedepartment.com/downloads/spotter-plugin-v2-17-by-carlomaker-f1dave.50356/

The only thing I could dig for now would be to have a kind of race engineer for you and your pace (comparing last lap and best - comparing some telemetry over few turns (you made it better in turn 3, or you loose too much in X)
But this wouldn’t be really precise as it’s would require to automate interpretation and could lead to inaccurate date (if you cut a chicane for example). This telemetry doesn’t provide enough data to have something really efficient. But for post race analysis it’s already a great step

 

[tarnheld]

Remember 0x44? I thought it was useless, but i didn't check thoroughly enough. It's actually the fuel level value! In a race with fuel consumption it will drop according to the fuel level display and will go back up if you pit.

 

[MCrisostomo]

The only thing I could dig for now would be to have a kind of race engineer for you and your pace (comparing last lap and best - comparing some telemetry over few turns (you made it better in turn 3, or you loose too much in X)
But this wouldn’t be really precise as it’s would require to automate interpretation and could lead to inaccurate date (if you cut a chicane for example). This telemetry doesn’t provide enough data to have something really efficient. But for post race analysis it’s already a great step

It would be a good start

 

[Bornhall]

Remember 0x44? I thought it was useless, but i didn't check thoroughly enough. It's actually the fuel level value! In a race with fuel consumption it will drop according to the fuel level display and will go back up if you pit.

Nice find!

Edit @tarnheld : Weirdly enough, it doesn't seem to work properly on an EV vehicle... Just noticed in a lobby that it seemed to be starting at 74-75% "fuel" on the EV I tested with (I think it was the Taycan or the Jag VGT – the only two pure EVs I have). Also, the "fuel", or charge rather, I guess, went down in quite large increments of around 4% for each drop, i.e. 74%->71%->67% and so on.

 

[Bornhall]

Remember 0x44? I thought it was useless, but i didn't check thoroughly enough. It's actually the fuel level value! In a race with fuel consumption it will drop according to the fuel level display and will go back up if you pit.

Oh, right, about 0x48, it is most definitely going to 0 instead of 100 on an EV car. Still haven't found any inkling as to anything in between, even though I've tested a variety of cars like the Tomahawk, Super Formula, 919 LMP1, Jag VGT, Taycan and nitro-equipped cars in time trial, arcade race and lobbies. It's weird...

 

[ddm]

Remember 0x44? I thought it was useless, but i didn't check thoroughly enough. It's actually the fuel level value! In a race with fuel consumption it will drop according to the fuel level display and will go back up if you pit.

In litres as well it seems: I have a telemetry dump from an electric car (which has 0L fuel capacity) and it correctly shows 0L.
Untested but it should show 5 for the kart, as the kart only has a 5L fuel tank.
(All non-electric cars have a 100L tank, only fuel consumption varies.)

Somewhat related: I did some testing earlier to try and figure out the fuel consumption formula, but unfortunately it seems to be more than just RPM & Throttle level. Torque most likely plays a part, so I'll have to map out the torque graphs of cars and do annoying maths to figure out the actual formula it seems...
(Tests ran on race cars only: race cars and road cars are known to have varying formulas. Race car engine fuel consumption modifier was calculated out.)

 

[Bornhall]

In litres as well it seems: I have a telemetry dump from an electric car (which has 0L fuel capacity) and it correctly shows 0L.
Untested but it should show 5 for the kart, as the kart only has a 5L fuel tank.
(All non-electric cars have a 100L tank, only fuel consumption varies.)

Don't have the kart, but that could square it up with the Taycan possibly having a 75 kW battery? Damn, now I've got to go check!

 

[Nenkai]

0x48 therefore means that it is the max fuel capacity.

 

[ddm]

Don't have the kart, but that could square it up with the Taycan possibly having a 75 kW battery? Damn, now I've got to go check!

? wdym by it squaring up with the Taycan?
Battery capacity isn't the same as fuel capacity, and the Taycan Turbo S in-game has a 93kWh battery anyway lmao
(93.4kWh in reality, only 93.0kWh in-game. Guess they just rounded it by accident.)

 

[tarnheld]

In litres as well it seems: I have a telemetry dump from an electric car (which has 0L fuel capacity) and it correctly shows 0L.
Untested but it should show 5 for the kart, as the kart only has a 5L fuel tank.
(All non-electric cars have a 100L tank, only fuel consumption varies.)

Ahh, that explains @Bornhall' findings!

Somewhat related: I did some testing earlier to try and figure out the fuel consumption formula, but unfortunately it seems to be more than just RPM & Throttle level. I suspect torque and/or aero are also used in that formula.
(Tests ran on race cars only: race cars and road cars are known to have varying formulas. Race car engine fuel consumption modifier was calculated out.)

There are also the Eco Fuel settings which feature prominently in the Eco Challenges in the Missions. You can adjust how much fuel is used at the expense of engine power, those are accessed like the TCS settings and are active if you have fuel consumption. To the total fuel consumptions might be rather complex. But you might have some change to get an estimation by noting how many fuel was used over the last lap time or another fixed time amount and then calculating how many laps would be possible if this fuel consumption continues to hold. Something like (given last lap time Lt in ms):

• save fuel F0 and time t0 (day time progression in ms)
• skip n packets
• get fuel F1 and t1
• calc dF = F0-F1 and dt = t1-t0
• calc fuel consumption per lap estimate FpL = dF/dt*Lt
• calc laps remaining LR = FpL/F1

Now you can save F1 and t1 and do another estimate after n packets again.

 

[ddm]

You can adjust how much fuel is used at the expense of engine power, those are accessed like the TCS settings and are active if you have fuel consumption.

GT Sport had this, and the way this worked was known thanks to trial and error & imo there's nothing to suggest they have changed for GT7:

rex1825

@1 - 100% power/100% range
@2 - 96% power/112% range
@3 - 92% power/123% range
@4 - 88% power/135% range
@5 - 84% power/146% range
@6 - 80% power/158% range

Basically, -4% power / -10% fuel consumption per fuel map level.
Power decrease is additive, fuel use decrease is multiplicative.

I can retest that but I don't expect any difference from these values.

 

[Bornhall]

0x48 therefore means that it is the max fuel capacity.

Yep, the kart confirmed that. 0x48 went straight to 5 on that field.

Battery capacity isn't the same as fuel capacity, and the Taycan Turbo S in-game has a 93kWh battery anyway lmao

Well, I meant that it meant that it could be kW instead of litres for the EVs, and besides, the https://ev-database.org/car/1116/Porsche-Taycan-Turbo-S says "useable battery" is 83 something kW.

However, looking at the value now, on SSRX in the Taycan, it went from 0 at start, then up to 80, then up 82 then 95 and it's now at 118. So not sure what the value is showing for an EV.

Up to 125 now... Could it be some kind of range value?

Edit: My mistake there, I forgot to set fuel consumption... But it does seem the Taycan starts out on something like 80 kW.

 

[Bornhall]

Right. I believe it is like this...

Seeing as all cars(?) except the kart can carry 100 liters of fuel (let's assume so, at least, seems to be the general consensus), is it also not safe to assume that all EVs in the game has something like 80 kWh, to put them on equal footing "fuel"-wise?

As mentioned, I only have two EVs at the moment; the Taycan and the Jag VGT. Both seem to drop down to 79 (from 0) after start. If anyone else can confirm, it would of course be great.

Edit: Yeah, no, that's likely not the case. See my next comment below.

 

[ddm]

Seeing as all cars(?) except the kart can carry 100 liters of fuel (let's assume so, at least, seems to be the general consensus), is it also not safe to assume that all EVs in the game has something like 80 kWh, to put them on equal footing "fuel"-wise?

It's not safe to assume that because I know for a fact it's not the case because I can look at the game data and tell you that's not how it works, lmao.

Fuel capacity is stored in the car chassis data and is always "100", except for the kart's "5" and electric cars' "0".
Battery capacity is stored in the electric motor data and is different for all cars (well, other than "0.0" for all cars without a battery).

The Jag VGT SV has a battery capacity of "100.0", the other Jag VGTs have a battery capacity of "60.0", and the Taycan Turbo S has a battery capacity of "93.0".

I have no idea why this value is appearing as anything other than 0 for electric cars: it is probably just a bug / data from the wrong place appearing.

 

[Bornhall]

It's not safe to assume that because I know for a fact it's not the case because I can look at the game data and tell you that's not how it works, lmao.

Fuel capacity is stored in the car chassis data and is always "100", except for the kart's "5" and electric cars' "0".
Battery capacity is stored in the electric motor data and is different for all cars (well, other than "0.0" for all cars without a battery).

The Jag VGT SV has a battery capacity of "100.0", the other Jag VGTs have a battery capacity of "60.0", and the Taycan Turbo S has a battery capacity of "93.0".

I have no idea why this value is appearing as anything other than 0 for electric cars.

Where are you getting the "car chassis data" and the "electric motor data" from?

But yeah, the value at 0x44 is weird for the EVs no matter... Just tested plodding along at 20-30 kph, and the value went up to 175 and higher. So strike my previous comment, it's definitely nothing we can assume about it yet.

 

[ddm]

Where are you getting the "car chassis data" and the "electric motor data" from?

... The game.
Via several private individuals that do not want it's public release because otherwise PD take notes and take actions to try and prohibit future access, as they've already tried to do (making it take much longer for the data to be extracted after each update, to the point where it's no longer a fast source of data for possible engine swaps) thanks to previous leaks hosted on this very site.

Actual detail on how the properties of released cars like this is not really a "leak" and I very much doubt PD would care about it:
but it would take significant time and effort to scrub every piece of content not in the game from this data, which is why the whole chunk will stay private unless PD themselves finally decide to put that effort in.

 

[tarnheld]

Updated the packet table with our new findings. One other thing to note: the day time progression value at 0x80 -- which is the only 'current' timestamp -- is affected the variable time speed ratio (VTSR) setting for custom races. It will elapse twice as fast if VTSR is set to 2x and more importantly not change at all when the VTSR is set to 0x. Since this is the only timing info available in the packet that's bad. I tried to check how often packets arrive and for me it's about 16 and 17 ms so about every 1/60s. Could be different for someone using a 120Hz monitor. Assuming a fixed packet time delta, one could infer VTSR from the packet time delta -- if the delta is 32-34ms we have 2x VTSR. For 0x VTSR all hope is lost, though...

 

[Stoobert]

Updated the packet table with our new findings. One other thing to note: the day time progression value at 0x80 -- which is the only 'current' timestamp -- is affected the variable time speed ratio (VTSR) setting for custom races, and elapse twice as fast if VTSR is set to 2x and more importantly not change at all when the VTSR is set to 0x. Since this is the only timing info available in the packet that's bad. I tried to check how often packets arrive and for me it's about 16 and 17 ms so about every 1/60s. Could be different for someone using a 120Hz monitor. Assuming a fixed packet time delta, one could infer VTSR from the packet time delta -- if the delta is 32-34ms we have 2x VTSR. For 0x VTSR all hope is lost, though...

I checked by adding packet time differences on to my data to check this and the PS5 definitely -tries- to send one at 1/60s intervals even at 120Hz refresh rate (looks like GT7 doesn't support it). Over the course of 30,000 data points the average packet time was 16.668ms, using Python's inaccurate time.time() module. Considering this library is correct to ~200us, that seems to be right. When colelcting data though, it may not be exact as I have seen packets arriving anywhere between 14-18ms.

 

[Skidude88]

.

 

[Betokafe2]

Eu adicionei uma opção --debug para exibir desconhecidos.

Release 1.0.1 · Nenkai/PDTools

Add debug option to print unknowns

github.com

Sim, isso serve. obrigada.

is it working on gtsport?

 

[NIKOLAUNCH]

is it working on gtsport?

Yes

 

[snimat]

Which of the available metrics should I use for spinning tires? I would like to track when I am loosing control. I have seen some prototype dashboards that mimic the red tires in GT7. But what metric are they using?

Also is there some metric that shows if I am steering? I would like to have an overview of the time when I am steering while breaking.