Freeplay UI fixes #4214
Freeplay UI fixes #4214
Conversation
Input is disabled as soon as possible when a capsule is open Input re-enables after capsule errors instrument selector uses the capsule's target position as it's position, rather than the capsule's position
github-actions
bot
added
pr: haxe
AbnormalPoof
added
type: minor bug
Lasercar
force-pushed
the
freeplay-ui-fixes
branch
from
d60189c to
85608bc
Compare
There was a problem hiding this comment.
Looks like most of the fixes work fine. There is one problem I've noticed though regarding the squished capsules. Whatever you did seems to have fixed it mostly as I don't see it anymore aside from one very specific circumstance. Here is a video of it happening:
Base.Profile.2025.02.24.-.20.27.44.18.mp4
Doing these exact steps should reproduce the bug consistently. Since this seems to be linked to the issue of normal songs being shown in freeplay after exiting an erect song, I think it's safe to assume that your PR #4088 will get rid of the issue. I'm going to approve this PR since it fixes exactly what it says it does, and once your other PR is merged, the squished capsule bug should be completely fixed.
Edit: This actually happens whenever you exit out of any song, and it's always Darnell BF Mix, I haven't seen it happen to any other song.
Lasercar
force-pushed
the
freeplay-ui-fixes
branch
from
6c766c1 to
734b9d2
Compare
Lasercar
force-pushed
the
freeplay-ui-fixes
branch
from
734b9d2 to
2ac8a5a
Compare
Does this PR close any issues? If so, link them below.
Fixes #3190, fixes #3627, fixes #4037, fixes #3703
Briefly describe the issue(s) fixed.
This PR fixes four issues - The letters not looping their animation and restarting it when selected, the lettersort input not being disabled when a capsule is opened, the first rank of a song overriding itself, and the instrument selector using the capsule's current position, rather than the position the capsule is targeting.
Also, if the capsule has a null target song or difficulty, it now also re-enables input before returning.
Another thing I noticed while doing this - only the random capsule does it's jump in, the rest of the capsules don't. I tried making the rest of the capsules jump in and I can see why they currently don't - they don't move very smoothly to their positions when they jump in and it looks really obvious. Setting the value to the targetPos.x rather than the capsule's x position fixes it, but then the capsules aren't set to their proper positions until you change selection. I'll figure out a fix proper fix for this later.
Also partially fixes #2659
Include any relevant screenshots or videos.
old video with fixes for the first two issues
2025-02-23.19-13-38.mp4
2025-02-24.22-21-05.mp4
2025-02-26.00-32-19.mp4