Fixing Autopilot by calculating between the lastJudgedObject and currentJudgedObject

[TaterToes]

• Successor to Fix Autopilot by calculating movement in the present time #32929

I decided to make a different pull request and close down the other pull request down since it seems fairly different, but this pull request is a bit more evolved. The new code remembers where and when you last made a hitobject judgement, then it calculates the percentage of time passed between the last hit object judgement to the next hitobject hitwindow. It applies that percentage to the distance between where the cursor was at the last hit object judgement to the position of the next hit object.

I want to do some heavy simplification on the code and some changes since it's almost 300 lines of code, but I'm again stuck so I decided to post a pull request to show that it works, but may need some changes due to performance issues and the size of the file.

Also personal note, coding this and in general, is really fun.

Here's a video below demonstrating the edited mod

2025-06-10.17-03-13.mp4

[TaterToes]

Ok, here's the current rundown as of currently.

ON INITIALIZATION

• Cursor is set to where the player last left it on screen.
• In stable I believe, It rises vertically towards the center. I'm generally inclined that this is the way to go. For personal preference, I just chose to set it where the player last had it before gameplay was fully loaded.

DURING GAMEPLAY (CURSOR MOVEMENT)

• There are subscriptions events that check the playfield for the last judged object. This will be needed to calculate time and position the cursor needs to travel.

• Based on last judgement, if we are somewhat far away from the next hitwindow of a hitobject, we will reach the center of the hit object at the time of start of the hitwindow. Keyword here is center, it will not enter the hitobject on start of the hitwindow.

• This is at the cost of no longer entering the hit object dead center in the hitwindow, which for visual players without rhythm might hurt them. However, this is a rhythm game and I subjectively believe should head in this direction.

• If we are too close to the hitwindow, I added a feature which doesn't make the cursor suddenly teleport to still make it somewhat visually pleasing. However, scaledTime (which is the mentioned feature) is not needed if we completely ignore visuals.

DURING REPLAY

• The new implementation interacts with the replay frames somewhat weirdly, so I blocked all the cursor calculations.

ISSUES FOUND

• When we pause gameplay, and reenter with our cursor at a different place, lastHitInfo.Position gets updated.
• Some mods cause the cursor to teleport.

OTHER FEATURES THAT COULD BE ADDED QUICKLY

• Since we no longer rely on replay frames, magnetized and repel could be added back as compatible mods, however rewatching the replay could be a different story.

---

CONCLUSION

Basically to make cursor reach the start of the hitwindow, the implementation compromises in visual cues, while trying it's best to retain it. The implementation aims to give the player as much room to give judgement on tap.

And personal note, currently ready for review.