JuiceStreams show incorrect snapping value

[UnluckyCroco]

Type

Game behaviour

Bug description

To clarify with snapping value I mean the box on the right which indicates the distance between the current object and the next (at least that's what it did in stable)

It seems JuiceStreams calculate snapping value based on the start of the JuiceStream (instead of the end).

In the video below the first JuiceStream should have a snapping value of about 0x, while it has a value of 0.69x. The second JuiceStream should have a value of about 3x, but instead has a value of 0.17x.

Screenshots or videos

donque.mp4

Version

2024.817.0-lazer

Logs

compressed-logs.zip

[peppy]

I don't quite understand what you expect from the value, and how you would use this. Like you say it should be "0x" but what does this even mean to you?

[UnluckyCroco]

0x would mean the next object is directly above the current one, meaning no additional movement is required to hit it. Basically a higher value would mean higher distance between 2 objects. This value is important to us because we often adjust the Slider Velocity Multiplier so that a 1.00x is perfectly walkable, and gauge how far to place objects based on that.

So the reason the first JuiceStream should have a value of 0x is because the next object (in our case another JuiceStream) is on the same x coordinate, so it is directly above it. Instead it is 0.69x, which is the distance between the start of the first JuiceStream and the start of second JuiceStream.

For reference, the snapping values are also shown when selecting an object in stable on the top right corner of the editor:

In this case, in lazer only the "next" value is shown.

I hope this clarified it

[snalgae]

I kinda didn't realise the potential of the snapping bar until I found this issue here.

I want to clarify that lazer gives 1.65x snap for walks and 3.3x snap for dashes.

I would find having this snap useful to create specific distances of ratios of walks and dashes. If I want to create a distance that is .8x of a walk I could multiply 1.65x by it to get 1.32x snap. Or if I want a distance between a dash and a walk (1.5x) which would be roughly 2.48x snap. It is easier to measure out these ratios instead of measuring out pixels and better than placing it roughly there free-form, or trying to make ratios with the distance snap option.

There are some problems with snap bar that make it annoying (which I found):

• The snap is based on the first object that is next on the timeline
  I find it annoying that I can't see the snap while placing or moving an object unless it's next in the timeline. I want to see the whole pattern to create an accurate placement for a snap instead of having to create the ratio first and then scroll up, or estimate it roughly on the spot and go back to see if it works.

• 1.65x is unnecessary to base calculations on
  I need to make more math than having a ratio in mind for a placement of an object and I think 1x is preferable (considering Spyreex assumed it was 1x which was intuitive to them, but it was wrong)

• Snaps shown in the snapping bar of objects that go after a slider are based on the start of the slider instead of its end. (Spyreex's issue)
  This is a more visual example of the described issue

2024-09-02.14-21-44.mp4

[peppy]

Thanks for the clear explanation! Will be fixed by #29681.