Broken UDP telemetry fields in version 1.8.0
Product: EA SPORTS™ WRC
Platform:PC
Summarize your bug Certain new UDP telemetry fields cause the game to stop sending telemetry.
How often does the bug occur? Every time (100%)
Steps: How can we find the bug ourselves? Enable UDP telemetry on a custom config. Launch the game. Boot up any stage. Check if packages are sent. Include (one of) the broken new values (see below). Restart the game. Boot up any stage. Check again if packages are sent. For me, none are sent now.
What happens when the bug occurs? UDP telemetry is no longer sent to the specified port
What do you expect to see? UDP telemetry sent to the specified port. Possibly more info in the telemetry log file.
The broken values are:
stage_progress
stage_result_time
stage_result_time_penalty
stage_result_status
vehicle_tyre_state_fl
vehicle_tyre_state_fr
vehicle_tyre_state_b*, as well as the other new fields work.
Im using https://bitbucket.org/timonboehm/wrc_telemetry/src/support1.8.0/ to read and visualize the packets.
It is unrelated to simhub. Not sure if that info is relevant
Hey @housegamer1
Thanks for the report!
We've run a few tests on our end using our own implementation of a telemetry logging tool and we're struggling to repro the issue. We've added "stage_progress" to the end of the default "custom1" packet and seen good values coming through. Likewise we've stripped "custom1" back to just contain "stage_progress" and also seen good values come through again, so data seems to be coming through correctly on our end.
We've had a bit of a skim through the scripts you linked and think we may have spotted some bugs in there that could be the cause of your issues. We'll give some details below - it'll be worth getting in touch with the creator of the scripts to see if these are valid concerns and find some fixes. Another thing to try is to clear our the telemetry folder of the game (it should be here: C:\Users\<YOUR USERNAME>\Documents\My Games\WRC\telemetry). It'll recreate the entire contents in a default state that we know works. Then you can layer in your changes again until it breaks...or hopefully doesn't. If the problem still persists, please zip up the contents of the telemetry folder (making sure to include the log file and all of the json configuration files) and send it to us and we'll give it a try on our end.Details on the potential bug we spotted in the scripts:
Inside main.py, we see on line 29 of the latest revision that it only reads 256 bytes from the network. However, the parser code in interpret.py in the function interpretCustom1() implies that it'll try to read values beyond 256 bytes. According to the Python docs, the extra bytes that aren't being read-in will be discarded, so values can't be parsed out of them unless they're read-in by main.py. The values you've reported as not functioning are all commented out/reporting default values by the script currently, but the previous revision of the file tried to parse them from these higher byte locations which, as noted, won't work as those bytes aren't read-in and would've caused crashes/malfunctions in the script. There are a few potential fixes that we'll need to leave up to the author of the scripts. The simplest we can see is to increase the size of the read-in buffer, and re-instate the parsing of the extra values - but that may have other knock-ons in other areas of the scripts we've not looked at, so take this with a health pinch of salt.Hope this is of some help!
