segment hash id

[mayfield]

Hi,

I'm curious if you've ever attempted to correlate the segment entries with the segment "hash id". These are the sint64 values used by the segments api's, such as -9223372027220687690.

[andipaetzold]

Hey,

could you please provide some more context? Are you talking about Strava or Zwift segments?

Until now, I didn't do any additional correlation and just used the ids as... ids.

[mayfield]

The in-game Zwift segments that you see on the leaderboard widget.

It's the ID used for the Zwift api's /api/segment-results/<hashid> and /live-segment-results-service/leaderboard/<hashid> if that helps. I can't seem to find a single API to get from this "hashid" to the "slug" in your segments.js contents. Without that mapping there isn't a good way to get meta details about the segment, like it's pretty name.

[andipaetzold]

I haven't worked with the Zwift API at all. The whole list of segments is manually collected and manually maintained.
The slug is also manually created, so you won't find any "officially" mapping anywhere.
If you have a list of all Zwift segment ids, I can add them to the repo so you can properly identify the segments.

[mayfield]

Thanks @andipaetzold I'll see what I can dig up then.

[mayfield]

Might have a lead on decompressing the .wad files with https://gitlab.com/r3dey3/zwift-utils

I just decompressed every wad file I could find in the game and searched for a non segment hash id to find this...

<ent type="ENTITY_TYPE_TIMINGARCH" m_roadTime="0.1840789487" m_archGdePath="data/Environment/Structures/KOM_Arch.gde" m_startLineSplineTimeF="0.0919000000" m_beginTimerSplineTimeF="0.0919000000" m_startLineSplineTimeR="0.3791000000" m_beginTimerSplineTimeR="0.3791000000" m_minTimeF="40.0000000000" m_minTimeR="100.0000000000" m_ArchColor="4278190335" m_ArchIconPath="UI/WhiteOrangeTheme/HUD/PolkaJersey_Icon.tga" m_ArchFriendlyName="Zwift KOM" m_ArchFriendlyFemaleName="Zwift QOM" m_ArchFriendlyNameR="Zwift KOM" m_ArchFriendlyFemaleNameR="Zwift QOM" m_ArchSegmentAvgInclineF="5" m_ArchSegmentDistanceF="0.8999999762" m_ArchSegmentAvgInclineR="2" m_ArchSegmentDistanceR="2.4000000954" m_ArchAlertTime="0.0500000007" m_bDontGenerateHashes="1" m_overrideNetworkHashF="9634088118" m_overrideNetworkHashR="-9223372027220687690" m_ArchId="2" m_jerseyIconPath="UI/WhiteOrangeTheme/HUD/PolkaJersey_Icon.tga" m_pinIconPath="UI/WhiteOrangeTheme/HUD/Marker_KOM.tga" m_jerseyPath="Humans/Jerseys/Originals/KOM_01.tgax" m_jerseyPath_Female="Humans/Jerseys/Originals/QOM.tgax" m_minimapIconPath="UI/minimap/map_arch_kom.tga">

[mayfield]

Hi @andipaetzold I have listings of the in-game segment identifiers. Assuming you're still open to adding some of these ids, would you like a PR and if so which file is the correct one to make changes to? I see quite a bit of automation so I'm not sure which files are generated.

[andipaetzold]

Hey,

It would be great if you could add the hash ids to the segments!
For routes, I have added the signature property of the public game dictionary as an id property to zwift-data, so I think we can do the same for segments.

I just reread your initial message which says that the ids would be "sint64" values, but you give an example with a negative number. Are you sure that you didn't run into an integer overflow here?

You can add the ids here. The TypeScript type is defined here. After adding the new property, simply run npm run update-data (might take a bit) and segments.ts should be automatically updated.

[mayfield]

Hi @andipaetzold,

Sounds good, I'll start mapping up the data.

Re the type: That's correct, they are using signed 64 bit numbers, most likely the result of a cast/rollover bug in their early impl. To make it even more interesting you must use an uint64 for the protobuf def and then manually cast to a sint64 to get the correct value expected by their REST API and to match what's in the world entities.xml files bundled with the game. Thought I was going crazy when trying to figure that one out.