Get rid of consecutive LNs #15

Closed
lifthrasiir opened this Issue Mar 7, 2013 · 1 comment

Projects

None yet

1 participant

@lifthrasiir
Owner

Consecutive LNs had been a source of problems:

  • 2.0 branch had consecutive LN parsing wrong (first introduced by git rev cb72f2f, fixed by git rev d242076). It accidentally removed LNSTART when LNDONE is present.
  • #LNTYPE 2 parsing is much more complex due to consecutive LNs.
  • As BMS command memo describes, Angolmois' handling of consecutive LNs lead to the possible incompatibility. If we disallow consecutive LNs we can just let AAAABBBB parse like AAAAAAAA.
  • In 2.0 branch (and also possibly 1.0) consecutive LNs are mostly unplayable due to strange grading: the start of second LN cannot be graded (and eventually graded MISS) if the key is pressed up and down earlier than the shared endpoint. This is because an imaginary "grading area" of the start of second LN is contracted due to the end of first LN (in spite of the grading area of the end of first LN is not contracted as LNDONE is checked separately). This can also occur if two LNs have very small gap, but consecutive LNs result in the most severe instance.
  • The current display of LNs cannot distinguish two consecutive LNs apart.

So let's get rid of consecutive LNs. That should make things much more clearer, and also saves a few lines (estimated). Checklists:

  • Check if there are BMSes with intentional consecutive LNs
  • Remove special casing of consecutive LNs in #LNTYPE 2 parsing; that should make #LNTYPE 2 parsing routine not to use prev in the current sense (last observed non-zero key in channels 5x/6x), and possibly to unify iprev, prev and lprev to have same meanings (the start of LN).
  • Simplify sanitization routine. I think there also exists some complex bug with BOMB/INVNOTE inside LN...
  • Update documents.
@lifthrasiir lifthrasiir added a commit that referenced this issue Mar 9, 2013
@lifthrasiir #15: dropped support of consecutive LNs and simplified sanitization a…
…lgorithm.

- #LNTYPE 2 consecutive LN behavior is removed.
- sanitization algorithm will always keep only one type of most importance,
  with an exception of BOMB (which can be overlapped with INVNOTE).
- parser still guarantees that every LNSTART has LNDONE somewhere behind it.
- overlapping LNSTART/LNDONE is explicitly checked to avoid stranger result.
  consequently LNSTART/LNDONE order is no longer important.

--HG--
branch : 2.0
5e6c780
@lifthrasiir lifthrasiir added a commit that referenced this issue Mar 9, 2013
@lifthrasiir updated documents for consistent terms, acknowledgements and changes in
#15.

note to translators: you are *strongly* advised to use wdiff for this change.

--HG--
branch : 2.0
282d4cc
@lifthrasiir
Owner

Search for possible intentional consecutive LNs is ended with the failure (my BMS collection doesn't have them). According to Hitkey #LNTYPE 2 was essentially unknown outside Korea anyway, so I think it is safe to assume that Korean BMS creators do not try to exploit this possibility.

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