Moving objects on mouseover getting stuck when cursor moves too fast

[Crimson Wizard]

Now we leave the cursor in this position. Since the card is no longer selected, it will begin to drop back to its original position, but this makes it pass over the cursor and get selected again, and so we're back to the bouncing. By adding the mouse movement check, we avoid this: in order to produce bouncing you have to keep jiggling the mouse, and in that case having the card rapidly selected and deselected is expected behavior.

Another way to handle this case would be to include the whole region the card passes over as it moves as part of the "buffer zone" (where it maintains a selection once the selection has been triggered), but that's more complicated.

I was kind of expecting that the "second way" is used, meaning that the trigger zone is always the same, regardless of where the card is located in the current moment.

[Laura Hunt]

Now we leave the cursor in this position. Since the card is no longer selected, it will begin to drop back to its original position, but this makes it pass over the cursor and get selected again

This never happens because the trigger is the invisible card, not the "real" one. In fact, the "real" cards are not even clickable, so they don't get detected by mouseovers or object detections at all. Therefore "this makes it pass over the cursor and get selected again" is not a situation that can happen with this method because the trigger card (the invisible one) never moves.

I was kind of expecting that the "second way" is used, meaning that the trigger zone is always the same, regardless of where the card is located in the current moment.

That's exactly the way I'm doing it, yes.

[Snarky]

A-ha. I was going by your earlier statement:

The problem with this approach is the one I mentioned earlier to eri0o: "trigger" areas would stop corresponding to their visual representations.

Therefore I assumed you would use both the visible and the invisible cards as trigger areas. But if you think having part of the selected cards be outside of the trigger area and cause them to be unselected is not a problem, then sure. (You could even do that with hotspots, just having the overlapping card regions as a separate hotspot that matches whichever adjacent hotspot was last active.)

I was kind of expecting that the "second way" is used, meaning that the trigger zone is always the same, regardless of where the card is located in the current moment.

That's exactly the way I'm doing it, yes.

If by "second way" CW means the second alternative I described, it's not quite the same solution.

[Laura Hunt]

A-ha. I was going by your earlier statement:

The problem with this approach is the one I mentioned earlier to eri0o: "trigger" areas would stop corresponding to their visual representations.

Therefore I assumed you would use both the visible and the invisible cards as trigger areas. But if you think having part of the selected cards be outside of the trigger area and cause them to be unselected is not a problem, then sure.

The key "eureka" moment was CW's suggestion that the invisible cards should not move up and down, BUT their baselines should move to the front or to the back together with the "real" card that's being activated, making overlaps possible and making the trigger areas almost identical to their visible counterparts.

So sure, in the end there's a tiny area in the trigger card that doesn't match the "real" card exactly when the card is lifted (10 vertical pixels to be precise), but in my tests it's barely noticeable and never ruins the effect.

If by "second way" CW means the second alternative I described, it's not quite the same solution.

Honestly I'm kind of lost at this point with all this back and forth But long story short, what matters is that the dummy cards method works great, and it's solved my issue perfectly