Peppy says "wait for an initial implementation, and then provide feedback on it", which I think is totally backwards.
Discuss how notelock should function in Lazer before I or someone else implements it.

Notelock is necessary to prevent objects being hit out-of-order, the goal is to come up with a specification which minimally interferes with your ability to hit a pattern, but also disallows cheese strategies.

I choose to combine "note lock" into one word as I think it is easier to search for, and is less likely to be confused with other concepts.
--------------------------------------------------------------------------------------------

This is a bit hard to grasp but I think I understand it now.

You basically prevent the player from FC'ing a pattern when hitting it out of order with the second rule. Seems fair considering that you also can't hit patterns out of order with the current notelock, but with your specification it's possible that you accidentally hit B (from the example case) before A and then get locked out of an FC.
However this might be absolutely necessary to prevent out-of-order hitting.

I do like that your specification prevents the common notelock on spaced streams and ignores the hitwindows of hit objects, so you won't have that weird case where low OD can actually be harder.

Here are some points of contention which I think need to be discussed.

1
The effect of condition 1 is that you may click an object as soon as the previous object's center passes. The wording I used seems to be confusing some people, but I had to write it that way to account for 2B cases in an unambiguous manner.

Is this early enough, or would it be better to be able to click the second object even earlier? In theory condition 1 can be removed and object B can be clicked before object A even arrives, but this may cause players to get locked out of clicking A by accidentally clicking B first. When should B be first clickable and why?

2
Should one of the goals be to prevent overclicking of stacks? ie you tap a slow stack perfectly but with one extra click, and now all objects are being hit so early that you miss, rather than missing one object and getting 300 on the rest. If so, how would you have notelock work to address that case?

Check if this is a correct representation of what you are proposing



Link to diagram: https://drive.google.com/file/d/1-bFBqzn1tujxNDXMWNuQDAk3nc598Aif/view?usp=sharing

I like this one :



Here in osu!, we're not playing solo, we accompany the music played by a .mp3,
this .mp3 can be seen as others musicians in a band/orchestra.
You can't say to your band "hey guys i missed a note, wait for me".
If you're not happy with a miss, click esc and retry,
forcing the player to fail by locking the following notes makes no sense.

Sorry for my english.

why have it at all

abraker, you got it right, that is a very literal translation. I would add that T is the current time, and once T passes the 3rd circle, the object at t1 can be clicked (seems to be hard to understand for some people).

Juuuuuuuuul, that specification gives smaller hitwindows than mine in most cases (which may not be a bad thing).
Half way through the 100 window in either direction is 39.5ms at od10, 53.5ms at od8. Aside from how it handles 2B, this is the only functional difference; in my spec the object becomes clickable depending on the time of the previous object, 60ms at 250bpm stream or 100ms at 150bpm stream.
The "cause all previous but still active notes to instantly miss" part is equivalent to criterion 2 in my spec, that is actually a better description for it.

unko, the main important feature is that you can't click stuff out of order. The way this is implemented is important to get right, because we don't want to cause players to miss things they deserve to have hit, but also don't want to create methods of cheesing patterns or slider score bug.

why is it a bad thing

unko, clicking objects out of order is cheesing a pattern, and not how it was meant to be played.

Karoo13 wrote:

Juuuuuuuuul, that specification gives smaller hitwindows than mine in most cases. It is also poorly defined, "if a note is clicked out of order and at the wrong time" lacks the details defining what is considered out of order and what is the right time. The "cause all previous but still active notes to instantly miss" part is equivalent to criterion 2 in my spec, that may be a better wording for it.

And i think that's why he wrote "Exact range for this is debatable".
Anyway, as long as the solution is not forcing the player to go back to a previous note if this one was missed and let the player keeping the correct rhythm, i'm ok with it.

I edited my post while you were writing this, since I realized he included a possible definition below, as half way through the 100 window. Part of what I would like discussed in this thread is what that exact range should be and why.

To reiterate, Millhi's spec determines how early an object should become clickable based on its OD:
Half way through the 100 window is 39.5ms at od10, 53.5ms at od8, value subject to tweaking.

My spec determines how early an object should become clickable based on the time of the previous object:
60ms at 250bpm stream or 100ms at 150bpm stream.

nothing is how this game was meant to be played anymore we've come about 13 years from that.not to mention the game's developers have already gone out of their way to implement cheesing before, in the form of doubletapping

I see, thanks for the clarification !

unko wrote:

nothing is how this game was meant to be played anymore we've come about 13 years from that.not to mention the game's developers have already gone out of their way to implement cheesing before, in the form of doubletapping

This discussion is about how to exactly implement notelock with the assumption that we want notelock.

If necessary there can be a public poll to know whether to add notelock at all.

i have a hard time understanding any of this tbh because im bad at understanding variables, can you explain it in a way that uses actual circles and timestamps instead of variables or no?

I rewrote the spec in top post, functionally unchanged so far but the definitions are a bit more precise and, I hope, easier to understand.

Imo I'd rather have the millhiore definition. The current implementation is to be at least at t1, which usually led to my doom when missreading on ezdt. Mill proposed halfway in 100, I also don't like the current but would say unlock it as soon as it is hittable (getting a 50) and let player then adjust himself back to the correct beat.

The current implementation, if you mean stable, is that the previous object's 50 window must be over.
My proposal is that the previous object's center must be over.
Millhi's proposal is that the current object's 100 window (or the second half of it) must have started.
Yours is that the current object's 50 window must have started.

I think any of the last 3 are potentially viable, and they have pros and cons. For ez mod, what specific patterns did you misread, at what bpm and od, and did you have extra clicks? it would be good to compare these in those situations.

Loki wrote:

i have a hard time understanding any of this tbh because im bad at understanding variables, can you explain it in a way that uses actual circles and timestamps instead of variables or no?

I made a diagram. Scroll up >_>

@unko i think notelock is important in some form just to prevent ppl from hitting stuff out-of-order (as others have mentioned)

consider a very fast pattern with overlapping jumps:

(1)3)                                  (2)4)

( do u like my shitty representation of overlapping in text)

with any form of notelock you must play this in order, 1 2 3 4. it's extremely difficult as intended. without notelock, you could hit 1 3 2 4 instead, taking away almost all of the difficulty. if they're close enough in time you could even SS the pattern like that

also idk where you got the idea that developers purposefully implemented the ability to doubletap. that's a natural consequence of having two keys available, and you would have to go out of your way to prevent it

Karoo13 wrote:

The current implementation, if you mean stable, is that the previous object's 50 window must be over.

Well I guess I didn't tested enough (also only validated myself with one map and 15 seconds of testing). Even tho, this still cause an issue with high density and low od, for instance, past 188bpm od8 on ez the 50 hitwindow is longer than the actual time between a 1/2.

Karoo13 wrote:

For ez mod, what specific patterns did you misread, at what bpm and od, and did you have extra clicks? it would be good to compare these in those situations.

Od~=4
I would say reading skills are personal. In my case that is the classic too many overlaps to keep track and also inconsistant rhythm. This mostly occur at higher bpm because you have less time to read, but this applies to lower bpm as well. There are not really any extra clics leading to the notelock itself, I just hit the wrong circle or fail to see it, but because of the current implementation, that would lead to a notelock because the 50 window of the last note isn't over yet.

Playing a bit more with ez while taking a look at notelocks, the same issue occurs not only because of misreading, but just missing in general. If you miss a jump and are hitting early/justontime, then you notelock. Obviously also applies to "spaced" streams. You move a bit too fast and there goes all 3 ez lives.

Karoo solution would reduce the occurance, it doesn't solve them all. For instance a 1/12 or 1/8 circle+slider combo, even in nm, given a certain bpm someone may be forced to miss the slider because of a missaim on the circle and doubletapped the wrong location. In contrast, my solution solve them all but cause that t0>t1 to occur, which can be weird.



Also abraker your diagram is just as hard to understand

The way I see it, there are 2 important cases to handle as the player intended, you are only addressing the first one:

1. Really early click after a misaim
If you want to hit the next object after a misaim, you want it to become available to hit as early as possible.

2. Misaimed click lands on a later object
In this case, the player probably doesn't intend to go for the object they just misaimed again (this is a point LTyyyy made in the reddit post about human reaction time), but they do still intend to hit all following objects, including the one they misclicked on but with correct timing, so the click should be ignored. For this, we want to notelock if it is likely the player didn't mean to go for that object yet.

xenal wrote:

Also abraker your diagram is just as hard to understand

Please help me make it easier to understand. What confuses you?

I have been reading older conversations and everyone seems to agree with skip object => miss prior objects, so the only variable part would be what time an object first goes from shake to click (and 2B). A lot of people don't consider forced miss on prior objects to actually be notelock, I originally considered it part of the same system but since most people seem to think otherwise, I will separate it into [notelock: just shake on click] and [out of order judgment handling], which can also include short sliders where you might hit the sliderhead after it ends.

My opinion is that notelock should be as fair as possible, not as easy as possible, and should also be OD-independent (OD affects only judgement, not whether the click is accepted) and layout-independent. OD might be a useful way for a mapper to tune notelock though, so it might be necessary if the mapper is intended to have control over this.

So what is fair? I think allow clicks on the object the player was trying to hit, block clicks on an object the player did not mean to hit yet, but don't block clicks if they are the result of mashing or overtapping. It is impossible to know what the player was trying to hit based on object timing alone, but we can try to make assumptions which will give the correct result in the most common cases, and not be too punishing in the cases where they are wrong.
--------------------------------------------------------------------------------------------

1: Stream.... cutoff after prev-prev object's center (applies to all cases)
2: Stack...... cutoff after previous object's center (hit intended objects at intended times, assuming good acc)
..2*............... cutoff before previous object's center (hit unintended objects, cause extra clicks, allow bad acc)
3: Double.... cutoff before previous object's center (allow bad acc, low priority)
4: Antijump. cutoff after previous object's center
5: Misread... cutoff before previous object's center (allow misread)
..5*............... cutoff after previous object's center (disallow misread)

These are the best ways to handle various patterns (as I see them) for where exactly you switch from shaking to allowing a hit. There are trade-offs for anywhere you design the cutoff to land.

--------------------------------------------------------------------------------------------
New diagrams made with abraker:
The point of interest is where note 3 switches from white to purple. Two OD and object spacing cases are shown, but a range of others are possible.

MillihioreF's proposal is literaly the best proposal, second place comes to xenals. Something needs to be done about the notelock timing and how just bad it is in stable right now