Cursordance?

[RichardKanshen]

Okay, so, there are so many Cursordance bots and illegal programs that might lead to a ban. Most of them are according to YouTube videos pretty neat, but still, the risk of getting banned is quite high.

So, the question is...
How could it be implemented?
Basically, it could be implemented using on/off switch customization in Autoplay and Autopilot mods.

Customizations
All of the lower stated customizations will unlock after switching on the cursordance option

• Enable Cursordance skin - On enabling: Cursor middle will be glowing with colors slowly; Cursor trail will be longer and rainbow.
• Enable Spin Cursordance -
• When disabled: Autoplay/Autopilot will complete spinners in ellipses randomly rotated;
• When enabled: Autoplay/Autopilot will complete spinners in random patterns/shapes

Summary

So, I guess that this is everything I wanted to say in this Idea, big thanks to the osu!team for being awesome in osu!development :)

• Richard
  :)

[SonoSooS]

I would actually implement the cursordance part if I could get it end up merged into the game.

As for the rest, I didn't read enough code yet to know how much the rest is possible, but even if possible, I would rather do it only one feature at a time, to increase my chances of my efforts being merged into the main codebase.

The last thing I want is spending weeks on a feature, just for it getting permanently rejected just because a feature "would not fit the game", or some other reason.

I just need a developer/maintainer who has merge access to approve this, so I could start working on it.

[SonoSooS]

Those that I asked below peppy's ((it would still be cool to get this in)) reply.

Many years have elapsed since I originally ported my cursordance engine to lazer, and want to know if the requirements have changed since, should I or should I not touch existing autoplay infrastructure, etc.

Also should I try to get the existing cursordance merged, and add in the missing feature (that currently relies on fixed circle size) later?

Do we still want to implement it as the preset dropdown with no configurability? I've tried to minimize preset count while maximizing variety, but I don't know if many years later that's still adequate or not.

And if it's even a good or bad idea to have a fully rewritten autoplay generator engine that transmutes hit object data to Abstract Timing Event format, and then that gets used for the other autoplay engine(s). It's kind of necessary to do this transmutation due to the flexibility it offers to have the data represented in a different way, but due to subtle differences, it makes existing autoplays incompatible if we decide to use this engine as the Default.
Do we want two autoplay engines?

These are the most important details that I have extracted from my reply.

[bdach]

Many years have elapsed since I originally ported my cursordance engine to lazer, and want to know if the requirements have changed since, should I or should I not touch existing autoplay infrastructure, etc.

Question too vague for reasonable answer. I still stand by most things I said in the previous thread, e.g. there should be no "settings that depend on other settings" stuff.

Also should I try to get the existing cursordance merged, and add in the missing feature (that currently relies on fixed circle size) later?

Again vague. What is the missing feature? Why does "fixed circle size" matter? We're not changing circle size mid gameplay yet, are we?

Do we still want to implement it as the preset dropdown with no configurability? I've tried to minimize preset count while maximizing variety, but I don't know if many years later that's still adequate or not.

See answer 1 I guess.

And if it's even a good or bad idea to have a fully rewritten autoplay generator engine that transmutes hit object data to Abstract Timing Event format, and then that gets used for the other autoplay engine(s). It's kind of necessary to do this transmutation due to the flexibility it offers to have the data represented in a different way, but due to subtle differences, it makes existing autoplays incompatible if we decide to use this engine as the Default. Do we want two autoplay engines?

Hearing "abstract timing event format" makes me scared. Maybe don't "abstract" anything just yet?

Do you have an actual branch I can look at or something so we don't talk vagueries in circles?

[SonoSooS]

It's not too vague, it's just that some context depends on the earlier discussions (that I have linked).

I do have a branch, but please don't judge the code quality itself, just the functionality, as it has to be rewritten. It's a direct port to lazer from an even older codebase with terrible code style, so it leaves a lot to be desired.

master...SonoSooS:osu:osu-18030-autoplay-alt

Edit: also keep in mind, that this is nowhere near ready for meging, this is still just porting the functionality, while also having some git history, just in case reverting is necessary

[peppy]

The only real advice I can give is to try and dissect it into small changes if you are changing the autoplay engine itself.

It might be better to keep it all in its own mod (if that's not already how it's done) to avoid having to modify the existing code at all.

[SonoSooS]

I think that adding this below "Cinema" and "Autoplay" as a separate mod should be the good idea then, and that should avoid quite lot of the issues I have mentioned (here and in the previous posts), and also shouldn't modify "critical" code then, hopefully.