Make "frontend JS/HTML" great again!

[zelogik]

Todo: change breaking change with the new JSON API, and merge work done from @Peck07 (waiting pull requests :-D)

[zelogik]

@Peck07 :

I got that:

Not totally as your (position order)
Seem like the order is not correct, position it's implemented on your side? or its a bug we need to check.

What work (need a little more test/check)

• slider
• Total lap to finish
• Start / Stop
• websockTimer: and websockCount:

What I will check soon:

• add reset button (even if reset is triggered at start)
• add gate number slider, number player slider
• some initialisation problem on some variables
• fu*&ing message, working well before doing modification on the js side (ie: only sent one time now!)

todo: adapt the CSS/html taking gates number into consideration!

But we have an almost working version now :-D (but far from bug-free)

[Peck07]

It's a feature :) but yes, I've also encountered it. the algo is simple right now, if a rank comes in, and it's not "visible", just creates the line for it. If the ranks don't come in order, it won't be created in order :) (typically happens when you start/refresh the page while the Race is running) Fix shouldn't be complicated. And apart from the displayed order, everything is updated in the correct line.

Yes, of course a lot of things need some fine tuning, or have some little defect :) but that's only the beginning of a beautiful friendship :)

Edit: already corrected the position order: Peck07@a8fa532

[zelogik]

How to fix easily the position/rank change between too player? keep old value with the new position/rank -> put new value at new position/rank -> put back old value to old position/rank ...
seem like damn slow...

ie: I'm on the player name server<->client

Yes, of course a lot of things need some fine tuning, or have some little defect :) but that's only the beginning of a beautiful friendship :)
👍

[Peck07]

If the backend sends the changed positions... it will be updated automatically on the frontend (hopefully).
Edit: actually, I have seen this several times, and seems to work well, only the Names don't change, as they weren't really touched till this moment :) but you can see the IDs change positions.

Player name: I've started to read the config on the frontend side :)

[Peck07]

Made the player name/color handling: #7
it should work, but the config received has id-s with 0.

[zelogik]

In the serial: F and B
should send some conf with filled value

And both name and color values aren't read ...

[Peck07]

I have seen it, sends Player 1, 2, 3, 4 with colors, but the id-s are 0 for every record

[zelogik]

1h for looking why id-s are at 0 whatever I put/try... I was blind ... == instead = ... 👎

So yes!! color working :-D

[zelogik]

strange behaviour now, changed the player 2 number to 0112, and got 74, and half working color now...
Maybe time to sleep :-D

[Peck07]

Lol, 0112 was interpreted as an oct! :) which is 74 in dec.
Just remove the leading 0 from this line:
const uint32_t idList[] = { 1234, 0112, 1337, 2468, 0x4321, 0x2222, 0x1111, 0x1357};
As I've seen, it will be removed from the configuration json as well.

[zelogik]

Yes I have seen it... but as the receiver send 0x (hex) if i remember well, to test color i have put simple dec, and now it's cast in oct. it's a feature not a bug. So removing the leading 0 will be done for the testing, but need a sanity check, even more when there will be server <-> client id transmission.

[Peck07]

Right now the id-s are treated as integers, so it shouldn't matter if it's received in hex, but let's keep an eye on them :)

[zelogik]

man: snprintf,

remember:

std::string hexify(unsigned int n)
{
  std::string res;

  do
  {
    res += "0123456789ABCDEF"[n % 16];
    n >>= 4;
  } while(n);

  return std::string(res.rbegin(), res.rend());
}