Snap copied objects to grid using beat difference between objects

[kongehund]

Type

Game behaviour

Bug description

Currently, copying and pasting/cloning objects in the editor seems to paste them according to the time difference between each object and the position where you paste. In songs with variable BPM, this means that all objects except the first will not be snapped to the grid.

I suggest to use the grid difference instead of time difference, such that each object is placed on the grid corresponding to the same rhythm as the original, regardless of BPM changes.

I suppose this can be done by i.e. counting how many beats are between an object and the first object, and then calculating what time values that corresponds to. If I recall correctly, @OliBomby has already implemented the desired logic in Mapping Tools's ´Pattern Gallery´ section.

I don't think there is any scenario where pasting by time difference is preferred over beat difference.

Screenshots or videos

2024-12-25.18-39-12.mp4

Version

2024.1208.0-lazer

Logs

compressed-logs.zip

[bdach]

Not sure I agree with doing this unconditionally. I'd say doing this should be under a toggle or modifier.

Counterexample as to why doing this unconditionally may be wrong: Say you want to copy a 1/4-snapped pattern when 1/2 snap is active - your pattern will get stretched to 2x the duration, while that may not have been the intention.

[kongehund]

The logic I propose does not depend on the current active snap. Instead, if a pattern is 1/4 snapped, it will always be 1/4 snapped when you paste, regardless of the active grid. (It is BPM dependent - the amount of milliseconds for a 1/4 spacing depends only on BPM)

Because of this, the functionality of pasting would always work the exact same as it always has on single-bpm songs - as such, the only difference this makes is fixing the bug of pasting unsnapped in multi-bpm songs.

[OliBomby]

I guess bdach's point stands for a theoretical map that uses 1x BPM for normal parts and 2x BPM for fast parts. Because the BPMs are a factor of 2 away from eachother they kinda work like a single BPM and you'd expect it to not stretch patterns on copy paste? I can't think of any maps that do this though.

Pattern Gallery has toggles for all these pasting features but they are mostly useful when copying patterns from one mapset to another. I think in the case of copying within the same beatmap it is safe to scale with BPM unconditionally. Not to mention slider durations already unconditionally scale with the BPM.

[bdach]

I guess bdach's point stands for a theoretical map that uses 1x BPM for normal parts and 2x BPM for fast parts

catch might do something like this if they get their allowance in RC to double bpm to effectively double tick rate. But I guess it's niche.

Scaling with bpm makes a bit more sense to apply unconditionally, I tend to agree.