BSTAR (drag) not being parsed correctly in some cases

[gabeblack]

if the drag term has a leading zero(s), the code converts it to an integer (parseInt), but then back in to a string later when it gives it to parseFloat. This causes the leading zero to be dropped and it erroneously calculates the drag term.

I'm guessing that the nddot parameter suffers from the same issue.

[thkruz]

No disagreements on this bug.

  satrec.nddot = parseFloat(
    `.${parseInt(longstr1.substring(44, 50), 10)}E${longstr1.substring(
      50,
      52,
    )}`,
  );
  satrec.bstar = parseFloat(
    `${longstr1.substring(53, 54)}.${parseInt(
      longstr1.substring(54, 59),
      10,
    )}E${longstr1.substring(59, 61)}`,
  );

Full code here

The solution is to skip the parseInt all together:

satrec.nddot = parseFloat(
      `${tleLine1.substring(44, 45)}.${tleLine1.substring(45, 50)}E${tleLine1.substring(50, 52)}`,
    );
    satrec.bstar = parseFloat(
      `${tleLine1.substring(53, 54)}.${tleLine1.substring(54, 59)}E${tleLine1.substring(59, 61)}`,
    );

Since this falls into the category of a fix vs an upgrade, I will try to get a PR in tomorrow.