Regarding Delta and TireWear in F1 24/25: The game does not directly provide delta or estimated time data. As for TireWear, the game does expose the relevant telemetry field, but it doesn't work as expected — this should be consistent with what you see in SimHub as well. So this appears to be a game-side data issue.
Regarding your Hub idea: This approach is likely not feasible. However, if you could share the specific method you have in mind, our development team would be happy to verify its feasibility.
Regarding custom telemetry configs: This is a fantastic suggestion, and honestly something we've been thinking about as well. Allowing users to define their own telemetry fields via JSON and have PitHouse pick them up automatically would be a powerful feature for the community. We can't commit to a timeline right now, but we've added this to our feature consideration list.
We really appreciate passionate users like you who push the platform forward. If you have more technical details or examples you'd like to share, feel free to send them to qlwang@gudsen.com
Please do not post unrelated content in the SDK Support forum. This thread will be removed within 48 hours.
Ry Mikky
Hello, Moza!
I play F1-series and use FSR2. Super-steering wheel, but I don't have enough information output. For example, GAP is really missing, TireWear is not working (F1-24/25). Question. Do I understand correctly that the PitHouse connects directly to UDP telemetry from the simulator and reinterprets the data itself? (I haven't looked at how it works yet, I've used the "configure" option). It's just that I decided to write a layer, a hub, between the game and the PitHouse. According to the scheme: Game -> Hub -> PitHouse. In order for the Hub to reinterpret the data so that the PitHouse understands it correctly. After all, there is " {
"name": "Gap",
"short_name": {
"zh_CN": "时间差",
"en_US": "DeltaToSessionBest"
},
"url": "v1/gameData/GAP",
"descs": {
"zh_CN": "预估当前圈耗时与个人最快圈耗时的差距",
"en_US": "Delta Time"
},
"data_type": "float",
"range": {
"zh_CN": "-∞~+∞",
"en_US": "-∞~+∞"
},
"package_level": 30,
"default_value": 0,
"compression": "float",
"is_visible": true
}, " This means that PitHouse can understand this telemetry. If you can't get inside the telemetry system, then maybe you can trick it a little bit? Should I "slip" the data to her in the right format?) By the way, would you consider the option to "open" the possibility for users to add their own telemetry config? Of course, I don't know if PitHouse has the ability to upload scripts to Runtime, but I think it would be a great thing! For example my_super_mega_telemetry.json "
{
"name": "MySuperMegaTelemetry",
"short_name": {
"zh_CN": "",
"en_US": "SuperTele"
},
"url": "v1/3rd_party(or customer, or someone else)/sup_tele",
"descs": {
"zh_CN": "",
"en_US": "MyOwnSuperMegaTelemetryNumberForWheelScreenDash"
},
"data_type": "int",
"range": {
"zh_CN": "-∞~+∞",
"en_US": "-∞~+∞"
},
"package_level": 30,
"default_value": 0,
"compression": "int",
"is_visible": true
},
" It seems to me that the community will become even bigger with the ability to write any telemetry and display it on the steering wheels. This is the main killer feature! In theory... this is done very simply. When launching the application, it scans a pre-installed directory with custom json telemetry configurations... and that's it))) and consider that they already exist in both the PitHouse and Dashboard Studio. Comfortable. P.S. I don't want to offend anyone, I just really want to customize my own display and get the full set of data that I personally need. It seems to me that many people are thinking about this.