The form doesn't accept "natural time" entry into the text field. The text field forces the user to enter hours and minutes and seconds and a space and milliseconds. So 25 seconds and 7 milliseconds has to be entered as:

00:00:27 700

Entering 00:00:27 7 will result in the old-style problem of 00:00:27 007.

The natural delimiter between seconds and milliseconds for most western countries is a dot/full stop character: . not a space.

Honestly, it's like you've given a description of a problem to an engineer that has never used a game or digital time in their life. It's a solution that imposes more problems that it sought to fix, surely?!

JJT_Defender, HighScorsese thanked this post

JJT_Defender, Rogerpoco liked this post

Some more findings.

You've clearly got a script acting on the user input into the text field but it offers the user no indication of issue until the form's Next is clicked.

It is possible to paste a valid time into the form with a full stop but this is not removed by the script which follows. Typing such a character is immediately removed so there's a script reacting to character input and but not an overall change to the field content.

The pop-up version of the individual element inputs will appear behind other elements depending on order of events - tested on Chrome (Windows), Firefox (Windows and Linux) and Safari (iPad). This seems to be based on natural top-down flow of the form. Using the form from the bottom-up tends to position the pop-up above the text inputs.

Truly minor: the written advice underneath the text input suggests that the milliseconds must be followed by a colon (:) character also. The written advice also suggests each element must be separated by a space.

Further considerations:

Users are going to input the values as shown by the game. Multiple games show times in an amount of seconds and milliseconds only (no minutes, etc.), so the likes of 123.456 is a perfectly valid output from such game:: 123 seconds. Having the script on the form convert this to it's internal required format would be an extra useful measure.

Stick to a widespread standard. While many game devs might have skipped looking for a standard due to time constraints (pun intended), they're not hard to find: https://en.wikipedia.org/wiki/ISO_8601 .

A simple set of valid input from the human perspective:

0

0.0

0.1

0.10

0.01

0.100

0.010

0.001

1

1.1

1.10

1.01

1.100

1.010

1.001

01

60

60.123

120

180

01:23.123

01:23.12

01:23.1

01:23.0

01:23

... & you know someone with a bunch of other valid human-perspective inputs... Hint: they run a scoreboard and have values displayed like https://www.twingalaxies.com/game/mario-kart-64/nintendo-64. ;)

JJT_Defender, Luigi Ruffolo thanked this post

Hi Barthax

We are working to resolve the issues. Will Update soon

Originally Posted by Barthax

Some more findings.

You've clearly got a script acting on the user input into the text field but it offers the user no indication of issue until the form's Next is clicked.

It is possible to paste a valid time into the form with a full stop but this is not removed by the script which follows. Typing such a character is immediately removed so there's a script reacting to character input and but not an overall change to the field content.

The pop-up version of the individual element inputs will appear behind other elements depending on order of events - tested on Chrome (Windows), Firefox (Windows and Linux) and Safari (iPad). This seems to be based on natural top-down flow of the form. Using the form from the bottom-up tends to position the pop-up above the text inputs.

Truly minor: the written advice underneath the text input suggests that the milliseconds must be followed by a colon (:) character also. The written advice also suggests each element must be separated by a space.

Further considerations:

Users are going to input the values as shown by the game. Multiple games show times in an amount of seconds and milliseconds only (no minutes, etc.), so the likes of 123.456 is a perfectly valid output from such game:: 123 seconds. Having the script on the form convert this to it's internal required format would be an extra useful measure.

Stick to a widespread standard. While many game devs might have skipped looking for a standard due to time constraints (pun intended), they're not hard to find: https://en.wikipedia.org/wiki/ISO_8601 .

A simple set of valid input from the human perspective:

0

0.0

0.1

0.10

0.01

0.100

0.010

0.001

1

1.1

1.10

1.01

1.100

1.010

1.001

01

60

60.123

120

180

01:23.123

01:23.12

01:23.1

01:23.0

01:23

... & you know someone with a bunch of other valid human-perspective inputs... Hint: they run a scoreboard and have values displayed like https://www.twingalaxies.com/game/mario-kart-64/nintendo-64. ;)

Barthax, Luigi Ruffolo thanked this post

After all the kinks are ironed out, I hope this is the start of better track creations. Crossing my fingers.

I think Pete covered this, but I'll be more precise. I'm entering a score right now and I see where there will be a problem--I 'm entering my time of 1:08.85......Someone may think that "85" from the drop down millisecond menu is the way to go, where it should be "850". Numbers 1-99 from the drop down milli menu should have a zero in front of them, 01-099, that way it's clear that 085 = .085 , which in my case would be the wrong way to go.

Barthax, jmb liked this post

Originally Posted by RaGeNyC

I think Pete covered this, but I'll be more precise. I'm entering a score right now and I see where there will be a problem--I 'm entering my time of 1:08.85......Someone may think that "85" from the drop down millisecond menu is the way to go, where it should be "850". Numbers 1-99 from the drop down milli menu should have a zero in front of them, 01-099, that way it's clear that 085 = .085 , which in my case would be the wrong way to go.

Despite using it a bunch, that one didn't occur to me: my perspective was entirely from the input field feeding the drop-downs. Good catch!

RaGeNyC thanked this post

Trying to submit a score and cannot get anything to be accepted in the time section. When I start typing in the format give in the text box, theres no way to enter 00 for either the hour nor minute. If I select the time from the drop downs there is an error message that they dont match and its impossible to edit them correctly in the text box.

Originally Posted by jmb

Trying to submit a score and cannot get anything to be accepted in the time section. When I start typing in the format give in the text box, theres no way to enter 00 for either the hour nor minute. If I select the time from the drop downs there is an error message that they dont match and its impossible to edit them correctly in the text box.

The manual entry of the time is working now but the decimal point has to be replaced with a space for it to be accepted.

The issue has been resolved .

The correct input format is hours:minutes:seconds.milliseconds

The millisecond format is 000 to 999.

Please let us know if you find any issues

Originally Posted by admin staff

The issue has been resolved .

The correct input format is hours:minutes:seconds.milliseconds

The millisecond format is 000 to 999.

Please let us know if you find any issues

I don't understand what target audience this is intended for. I would hazard a guess that this does not fit the purpose 99.999% of gamers of this site.

The gap between "fitting the engineering of software requirements behind the scenes" and "what the user needs" is even bigger than when you started to change the form.

We don't use handcranks on cars any more for good reason...

Originally Posted by Barthax

The gap between "fitting the engineering of software requirements behind the scenes" and "what the user needs" is even bigger than when you started to change the form.

1) Start with the assumption the time is 0 hours 0 minutes 0 seconds and 0 milliseconds.

2) Split user input based on ":" character. Number of elements confirms depth of unit values: 3 = hours:min:seconds.decimals; 2 = min:seconds.decimals; 1=seconds.decimals . Adjust the hours and minutes appropriately.

3) Last element is potentially seconds.decimals: split based on "." character: Integer = seconds only; . character = seconds.decimals.

4) Pad decimals to 3 digits, inserting 0 to the right: 123 = 123; 12 = 120; 1 = 100.

5) If seconds > 60 ; minutes += seconds /60 rounded to zero decimals; seconds = seconds mod 60.

6) If minutes > 60; hours += minutes / 60 rounded to zero decimals; minutes = minutes mod 60.

While they may not be able to break it down to this, this is what your user base is largely expecting to work from their user input. Especially note the distinction between the concepts of "decimals" and "milliseconds". TG requires milliseconds, the user does not: even if they voice it as "milliseconds" due to cultural impurities.