Visitar URL original
Fixes negative seconds visually (but not underlying cause) by EagleWorks · Pull Request #1949 · RocketMap/RocketMap · GitHub
Skip to content

Fixes negative seconds visually (but not underlying cause) - #1949

Open
EagleWorks wants to merge 1 commit into
RocketMap:developfrom
EagleWorks:Issue-1941-Fix-negative-seconds
Open

EagleWorks wants to merge 1 commit into
RocketMap:developfrom
EagleWorks:Issue-1941-Fix-negative-seconds

Conversation

@EagleWorks

@EagleWorks EagleWorks commented Mar 23, 2017 •

Copy link
Copy Markdown
Contributor

Spawn point details can currently show negative seconds. These should
be substracted from 60 to get the correct second count.
Note: This only fixes a formatting issue, not any issues with regard to
actual spawn times. For discussion on the latter, see Issue #1944

Description

Adds a ternary operator to subtract negative seconds from 60 to correct the negative seconds issue.

Motivation and Context

Negative seconds don't make sense in display formats, especially not when they're only negative if they're single-digit.

Seb edit: This fixes the visual issue caused by #1941, but not its underlying cause.

How Has This Been Tested?

Three-fold: In-map, using Calc, and using a javascript iteration over a range of numbers.
This change only affects displayed times in the spawn point details on the map.

Screenshots (if appropriate):

https://cloud.githubusercontent.com/assets/3775662/24132943/989aeda0-0dcf-11e7-9335-42e971672d6a.png

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.

The last two points are just a reminder to self that the front-end needs documentation, period :)

Spawn point details can currently show negative seconds.  These should
be substracted from 60 to get the correct second count.
Note: This only fixes a formatting issue, not any issues with regard to
actual spawn times.  For discussion on the latter, see Issue RocketMap#1944
@SiteEffect

SiteEffect commented Mar 23, 2017 •

Copy link
Copy Markdown
Contributor

The question is, is that a front-end issue or if there is something going wrong in the python part!?

@EagleWorks

Copy link
Copy Markdown
Contributor Author

@aRengo as per the summary, this fixes purely a display issue (a function that takes a value and returns a string for incorporation in the html), and doesn't touch any underlying issues with regard to whether or not the supplied value is actually correct. For that, see Issue #1944 and its discussion thread :)

@sebastienvercammen sebastienvercammen changed the title Fixes Issue 1941, negative seconds Fixes negative seconds visually (but not underlying cause) Apr 19, 2017

@sebastienvercammen sebastienvercammen left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've changed the title and description to be clearer on what it does and doesn't fix.

I'm personally on the fence about this PR, since negative seconds should never have been a problem in the first place if the back-end does its job properly. While it does fix the display for those cases where we get negative seconds (= bad), it tries to fix something that shouldn't exist, so I would keep this PR unmerged to make it very clear to us when something is going wrong with our timing.

In this case, I would fix the back-end issue rather than applying a front-end bandage.

Overall a good PR, but I vote no.

@EagleWorks

Copy link
Copy Markdown
Contributor Author

Yep - I vote the same if the underlying cause is coming up on fixes. Might be more appropriate to put checks for incorrect values earlier in the code (from the calling function, say) and display errors (even if just in dev console) explicitly?

@SiteEffect

Copy link
Copy Markdown
Contributor

Imo, while this is a well PR code-wise it just fixes a symptom and not the bug itself. So I vote no, too :-/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants