Jump to content

GTS class calculator and ratio mismatch


int2str
 Share

Recommended Posts

Since I might have to class my car in GTS soon, I've had a closer look at the GTS calculator and noticed a few issues. I've fixed some of them and am available to help further if needed. I've provided the problems below and potential solutions:

1. GTS ratio mismatch

I could find 3 different versions of the ratio tables:
1. The 2022 V5.0 rules
2. The FAQ on the GTS main website
3. The source code

All three sources have different values. I would consider the rules as the source of truth here.

Proposed solutions:
- Delete table in FAQ on web site; refer to rules
- Fix ratios in source code and indicate rules version (more below)

 

2. Rule ambiguity

The GTS rules (as far as I can tell), do not specify how average horsepower is calculated.
The rules simply state:

Quote

The following table shall be used to determine each car’s base minimum weight when multiplied by the engine’s average horsepower

Unlike the ST/TT rules, it is not stated which values are considered for the calculation of the average horsepower.
However, looking at the GTS calculator, the "average horsepower" is actually the highest average horsepower for a sliding window of values. It uses "Redline RPM / 400" values. 

For example:
If redline is 4250, then 11 rpm steps (or 1100 rpm) are  used to calculate the average.
4250 / 400 = 10.625 = rounded 11

There is an additional potential issue where the online calculator does not seem to take the horsepower value at the last RPM step into account. Since the calculation is not explained anywhere, it's unclear whether this is a bug in the online calculator or intentional.

Proposed solutions:
- Specify average calculation in rules
- And/or specify average calculation on the GTS calculator page

 

3. Code obfuscation / transparency

The online calculator code has been purposely obfuscated and is not available for inspection.
For non developers, here's what that looks like:

(function(_0x46f244,_0xfd2314){var _0xfe22f1=_0x28b5,_0x489fc3=_0x46f244();while(!![]){try{var _0x48416f=parseInt(_0xfe22f1(0x1d5))/0x1+parseInt(_0xfe22f1(0x1cc))/0x2+-parseInt(_0xfe22f1(0x1d2))/0x3*(-parseInt(_0xfe22f1(0x1eb))/0x4)+parseInt(_0xfe22f1(0x1e4))/0x5+-parseInt(_0xfe22f1(0x1d0))/0x6*(parseInt(_0xfe22f1(0x1fd))/0x7)+parseInt(_0xfe22f1(0x1cd))/0x8+parseInt(_0xfe22f1(0x1e9))/0x9*(-parseInt(_0xfe22f1(0x1d1))/0xa);if(_0x48416f===_0xfd2314)break;else _0x489fc3['push'](_0x489fc3['shift']());}catch(_0x41f60d){_0x489fc3['push'](_0x489fc3['shift']());}}}(_0x2abd,0xc5836));

Trust me, this is not what code normally looks like :)

It is unclear why the code was purposely encrypted like this. This just means it's not open to inspection and cannot be verified easily externally. This is obvious by the fact that the ratios in this code are wrong, for example.

Proposed solutions:
- For transparency reasons, code should be well readable and correct-by-inspection
- Refactor code for readability beyond obfuscation

With this in mind, I've gone ahead and refactored the code based on the criteria above.
I've attached the re-written code below.

It has been rewritten with transparency in mind and also has rules extracts interleaved with the code to make it clear when the code goes out-of-sync with the specifications and hopefully allows casual readers to spot any problems easily.

Here's an example:

function getMultiplier(params) {
  const table = ratio_tables[params.is_tubeframe ? 'tubeframe' : 'regular'];
  let ratio = table[params.gts - 1][params.is_dot_tire ? 0 : 1];

  // Rules 2022 5.0 | 6.3 Classification
  //  All FWD cars will be given minus .4 Correction Ratio,
  //  excluding non-production factory build race cars like Audi RS3 LMS, VW TCR
  //  and similar.
  if (params.is_eligible_fwd) ratio -= 0.4;

  // Rules 2022 5.0 | 6.4.4 Sequential/Dog Ring Type Gearboxes
  //  Sequential and Dog Ring gearboxes specifically intended for racing shall
  //  be assessed an additional plus 0.2 lb./hp penalty
  if (params.is_sequential) ratio += 0.2;

  return roundToOneDecimal(ratio);
}

 

Not sure who maintains this part of the GTS website.
Please feel free to use the attached code and don't hesitate to reach out if any additional help is required.

Hope this helps.

 

gts_calculator.js

Edited by int2str
Updated gts_calculator.js | Using object notation for initialization
  • Like 1
Link to comment
Share on other sites

1 hour ago, int2str said:

However, looking at the GTS calculator, the "average horsepower" is actually the highest average horsepower for a sliding window of values. It uses "Redline RPM / 400" values. 

For example:
If redline is 4250, then 11 rpm steps (or 1100 rpm) are  used to calculate the average.
4250 / 400 = 10.625 = rounded 11

 

You implied it, but just to be explicit - each RPM step is approximately 100 RPM wide.  So when the calculator uses "Redline RPM / 400" values of 100 RPM each, really it's using 25% of the redline range (Redline RPM / 400 * 100 = Redline RPM / 4)

 

Link to comment
Share on other sites

For the correct ratios always refer to the Rules. Thank you for pointing the inconsistencies on the website and such - we will fix it ASAP.

In regards to the calculator, we are looking into this as well. 
Appreciate the input and hope to see you running in GTS.

 

Michael G.

Nat GTS Dir.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...