[sugg] scroll with button instead of edge of screen

[mobius]

I don't like scrolling at the edge of the screen. It's especially annoying on vertical levels because you accidentally scroll every time you go the bar to press a button. But I've always found it annoying when for example you want to do something sort of near the edge of the screen; you accidentally scroll then lose what you were trying to do.

I'd prefer the option [like Lix has] to use a (assignable) button instead. Holding right mouse button then moving mouse scrolls. This can be used in conjunction with having your right mouse be used as something else also [like selecting walkers as I do] and won't conflict because you're not left clicking.

[namida]

NeoLemmix's hotkey system (which despite the name, includes the middle / right mouse buttons and the mouse wheel) doesn't currently allow for assigning multiple functions to one key.

The idea in general should be doable, though.

[namida]

I've implemented this for the next update.

There are two seperate options. The first is to assign a hotkey which gives the hold-to-scroll function. The second is to disable edge-of-screen scrolling.

I'm not sure how ideal the current implementation is, so I'll be releasing an experimental build shortly that can be used to test this out.

[Simon]

I tested player V10.13.17:bfe87e5 in wine.

The improved egde scrolling feels snappy and good. Very refreshing, makes the game feel modern.

I remapped hold-to-scroll to RMB. Hold-to-scroll feels quick enough for me. The mouse is always kept in the window, that is perfect. I'd always use this hold-to-scroll over edge scrolling.

geoo would probably like to configure it even faster because his mouse is set slow and insensitive.

NL keeps scrolling even after I stop moving the mouse. This feels slippery. I have the map in my mind and habitually hold-to-scroll with one quick, controlled movement to where I want. I'm not 100 % sure if, due to the extra scrolling after I stop moving the mouse, NL overshoots my target, or whether NL has undershot before and now approaches the goal slowly. I believe this extra scrolling overshoots.

NL doesn't freeze the mouse cursor when hold-to-scrolling. Different than what I do in Lix, but NL's behavior is straightforward and simple. Unless you're extremely close to the window edge, you can scroll everywhere in NL. I merely have the hunch that not-freezing is related to the slippery overshooting. What is the basic behavior for NL's hold-to-scroll?

Waiting for mobius's reaction to this hold-to-scroll.

-- Simon

[namida]

Here's the relevant parts of the code, with some comments added for this post:

Detecting initial press and activating hold-to-scroll mode

Code Select Expand

          lka_Scroll: begin
                        if PtInRect(Img.BoundsRect, Img.ParentToClient(ScreenToClient(Mouse.CursorPos))) and not fHoldScrollData.Active then
                        begin
                          fHoldScrollData.Active := true;
                          fHoldScrollData.StartCursor := Mouse.CursorPos;
                          fHoldScrollData.StartImg := FloatPoint(Img.OffsetHorz, Img.OffsetVert); // this doesn't get used, I thought I may have ended up using it but didn't
                        end;
                      end;

Processing hold-to-scroll

Code Select Expand

  procedure HandleHeldScroll;
  var
    HDiff, VDiff: Integer;
  begin
    HDiff := (Mouse.CursorPos.X - fHoldScrollData.StartCursor.X) div fInternalZoom; // fInternalZoom is the current magnification for the gameplay display
    VDiff := (Mouse.CursorPos.Y - fHoldScrollData.StartCursor.Y) div fInternalZoom; // just on the offchance this is a significant difference from C++ / D, "div" is integer division (truncating remainder)

    if Abs(HDiff) = 1 then
      fHoldScrollData.StartCursor.X := Mouse.CursorPos.X
    else
      fHoldScrollData.StartCursor.X := fHoldScrollData.StartCursor.X + (HDiff * 3 div 4);

    if Abs(VDiff) = 1 then
      fHoldScrollData.StartCursor.Y := Mouse.CursorPos.Y
    else
      fHoldScrollData.StartCursor.Y := fHoldScrollData.StartCursor.Y + (VDiff * 3 div 4);

    Img.BeginUpdate;
    Scroll(HDiff, VDiff); // Distances used by this procedure are in physics pixels, not screen pixels
    Img.EndUpdate;
  end;

Terminating hold-to-scroll

Code Select Expand

  ...else if fHoldScrollData.Active then
  begin
    if GameParams.Hotkeys.CheckForKey(lka_Scroll) then
      HandleHeldScroll
    else
      fHoldScrollData.Active := false;
  end else...

[namida]

mobius: Have you tried this feature out in the experimental yet? How are you finding it? (If you don't like it being on a keyboard key, it can be remapped to the middle or right mouse button in the hotkey configuration menu.)

[mobius]

I pretty much agree with Simon's comments. The edge scrolling speed is perfect imo

this exp version appears to have a glitch which I haven't seen before: when you pause and backtrack; the climber skill always gets selected. (no matter which skill is currently selected)

Also, during replays the skills selected don't seem mirror what's actually being selected. Though I seem to recall this particular thing being debated or changed recently.

[namida]

this exp version appears to have a glitch which I haven't seen before: when you pause and backtrack; the climber skill always gets selected. (no matter which skill is currently selected)

Didn't see this myself, but will look into it. I am aware of one bug in this experimental, where increasing / decreasing the release rate happens way too fast.

Also, during replays the skills selected don't seem mirror what's actually being selected. Though I seem to recall this particular thing being debated or changed recently.

This has been the case for a very long time now. At first it came in the form of an option to disable this functionality, but most people seemed to prefer disabling it. So nowdays, NeoLemmix doesn't even keep track of what skill was selected when.

[namida]

this exp version appears to have a glitch which I haven't seen before: when you pause and backtrack; the climber skill always gets selected. (no matter which skill is currently selected)

Didn't see this myself, but will look into it. I am aware of one bug in this experimental, where increasing / decreasing the release rate happens way too fast.

Forgot to mention it here, but this is long since fixed now.

Anyway, since there hasn't been further feedback on this, I'm closing this topic. Feel free to make a new one if you have any bug reports or further suggestions relating to this feature.