ppy
Make osu editor blueprint radius match skin radius
Makes the outer radius of the editor blueprint match the skin's object radius in osu ruleset.
https://github.com/user-attachments/assets/154651a1-cd6f-41c9-8241-3d9077d4d71f
The non-matching radius made it difficult to judge what the object actually looks like behind the blueprint,
This is an issue with every skin except Triangles (2017), with the radius difference even being big enough to have a (barely) visibile gap between the slider & the blueprint on argon skin.
Are you sure about this? The whole point and precedence of blueprint overlays is to show true sizing of the hit areas so mappers can plan correctly. By making this change, a mapper sees different results depending on their skin.
Personally I'm against this.
(kinda scary that olibomby seems to be for this change..)
You're right, it's not ideal. This is more of a bandaid fix for a larger issue, which is the hitobjects appearing with a different radius based on which skin you are using. There are other ways of addressing it, for example by rendering hitobjects with the same radius regardless of skin in the editor, though I believe that would be a much more invasive change which is why I opted for this.
As far as being able to judge the hit area, I think with the difference in radius being just a few pixels (5px for legacy skins), the impact it has visually is greater than the impact it would have on gameplay. This is of course just my personal opinion, but I care most about such small distances when the objects are really close together. When objects are so close together I typically care more about how big differences are relative to how far the other objects on screen are apart, which is exactly where the blueprints make things appear different than they actually are.
All circles have the same spacing in this screenshot. Notice the blueprint makes the spacing around the selected object appear smaller than around the other objects
when selecting 2 objects it even looks like they're overlapping
I'm open to make a new PR to address this in a different way if we can find a different solution that everyone can agree with.
I think you're missing the fact that if you switch away from the classic skin (which is the default for new installs), users are going to see that overlap in gameplay so should you not be mapping with that in mind?
I'm aware of that. Though the same argument could be made for mapping in stable. What I'm more concerned about here is how big the distances look relative to each other. While the circles would indeed be overlapping in that case, they would at least be overlapping consistently. I want to be able to tell whether or not objects on screen have consistent spacing, which is currently not possible when there is a selection or when placing objects.
I'll explain why I agree with the changes of this PR. First of all, mappers are designing an experience for the players, so its crucial to be able to see the beatmap how the players see it, that is with a skin. We can't change the fact that skins have various object radii, so the best you can do as a mapper is look at your map with various skins. If you map only to the true object radius, your map is still gonna look wrong in skins that don't use the true object radius, which seems to be most of the skins. That's why the blueprint showing the true object radius doesn't add much value. Instead its just noise that prevents you from seeing the radius of the skin, which is the radius you actually want to see.
Funny how a bit of drop shadow causes such issues.
If I were to suggest anything then maybe I'd say that if the issue is lack of consistency in spacing then the true clickable area should be properly indicated at all times instead (even if nothing is selected), but I know that if I say that in earnest I am going to have a crowd of people with torches at my door.
@bdach If that is done by adjusting the objects to render at the same radius as the clickable area in the editor regardless of skin I think that, while not ideal, it'd at least be an improvement over the status quo, even if it means maps will look different compared to stable. At least I can get around that issue by adjusting the map's circle size by a small amount while mapping.
You're right though, there's definitely people that would take issue with that appraoch.
@bdach If that is done by adjusting the objects to render at the same radius as the clickable area in the editor regardless of skin I think that, while not ideal, it'd at least be an improvement over the status quo, even if it means maps will look different compared to stable. At least I can get around that issue by adjusting the map's circle size by a small amount while mapping.
This is literally impossible. Unless you want to obliterate skinnability as we know it.
The thing I had in mind was more akin to adding an opaque circle behind each object with the proper radius showing. But again, it's not something I'm willing to actively pursue, because I know users will hate it.
The true clickable area should be properly indicated at all times instead
Yes, if anything there should be a way to see the true clickable area for the entire map regardless of selection. Maybe not at all times though. To show it at all times would require either changing all skins to match the true clickable area which is impossible, or adding an opaque circle behind each object with the proper radius showing which would be quite annoying.
I think the best way to show the true clickable area is to just switch to a skin that has the proper radius. This way the mapper can still look at the map the way it looks like in gameplay and choose themselves when they want to see the proper radius.
We can make the mapper more aware of the true clickable area by showing a warning when they edit a map with a skin that has an unrepresentative hit object radius. That would be skins with a radius smaller than the classic skin or bigger than the true clickable area. The warning could be like: "The skin you are using has a modified hit object radius. Your map might not look right when viewed with a different skin."
The selection blueprint is not the right place to show the true clickable area because it does not show for all hitobjects at the same time, so it fails at showing the mapper how the map as a whole looks with the true clickable areas. Also it does not properly communicate that the selection blueprint radius is meant to show the true clickable area. Instead the mapper is left questioning why the blueprint doesnt fit their hitobjects like its a bug. Therefore we need to fix blueprints ASAP and merge this PR.
With that logic we might as well just say fuck it and change argon/triangles to visually match classic skins and call it a day?
I'd be more inclined to do this than what is proposed in this PR.
With that logic we might as well just say fuck it and change argon/triangles to visually match classic skins and call it a day?
I'd be more inclined to do this than what is proposed in this PR.
I'm fine with that if we also change the editor blueprints to visually match classic skins. That is match the 5px difference between classic skins and the true clickable area.
@ppy/team-client thoughts on just doing the above (change triangles and argon skin to visually match the incorrect circle size of classic skins)? at this point in lazer's development where we are like "whatever with correctness" it seems like the right move to make? seems more "what the user expects"
Out of all the outcomes proposed here changing the two skins seems like the least bad one. I hate it, but I hate the others way more.
Actually there is another aspect to "change argon/triangles to visually match classic skins" which we haven't yet considered: The ratio of circle radius and slider body radius is not the same between argon and classic skins.
If you mean to also change the slider body radius of argon to match classic it will significantly change the appearance of the skin, and we'd lose a bit of the creative expression that initially went into the skin.
I think the ratio sliderbody radius / circle radius is a stylistic choice that can differ between skins. That is something you sacrifice if you plan to change all skins to have the same radii so you dont need more skin config properties to make editor blueprint radius match skin radius.
With the approach in this PR we don't have to sacrifice this customizability so I still think this PR is best.
What happens if we just don't change it though?
If we don't change the slider body radius we'll be where we are now. The selection blueprint will not match the radius of the slider body in the argon skin, because the argon skin uses a slimmer slider body than the classic skin.
Either we'll have to make the slider body part of the selection blueprint skinnable (like the direction of this PR), or make the argon sliderbody radius match that of stable, visually altering the skin. I prefer the former option because it doesn't alter the argon skin, improves skinning customisability, and skinning selection blueprints is something we should add eventually anyways because stable supports it too.
"Skinning customisability" should not entail "I am allowed to lie about what the clickable radius of an object is". We're unfortunately already there with the legacy default skin lying in such a way, and it will have to unfortunately be allowed in that context, but I want to see it stop there and go no further. Which would mean adjusting argon/triangles to match.
skinning selection blueprints is something we should add eventually anyways because stable supports it too
First of all, what? How does stable "support it"? And second, please no.
First of all, what? How does stable "support it"?
In stable you can use hitcircleselect.png in a skin to change the selection overlay. It's quite popular actually, a decent amount of the mapping skins I have override the default selection overlay.
Example of skin with custom selection overlay
I've even seen people go as far as placing rulers and stuff on the overlay, which does seem to go quite a bit beyond the intended purpose of it but to each their own.
"Skinning customisability" should not entail "I am allowed to lie about what the clickable radius of an object is". We're unfortunately already there with the legacy default skin lying in such a way, and it will have to unfortunately be allowed in that context, but I want to see it stop there and go no further. Which would mean adjusting argon/triangles to match.
I don't understand why you are so dead-set on having the selection blueprint show the true clickable radius while its clearly not the right place to visualize this radius, and even the necessity of seeing the true clickable radius is debatable.
necessity of seeing the true clickable radius is debatable
I don't think I've ever seen a single person say that they wish to be able to see this in stable, in fact I would be surprised if most people are even aware of the radius difference, because not seeing it doesn't really cause any issues. In the worst case the map is gonna end up a tiny bit easier than intended.
having the selection blueprint show the true clickable radius while its clearly not the right place to visualize this radius, and even the necessity of seeing the true clickable radius is debatable.
Discard all of your historical expectations for a second. Do you realise how insane this sounds in isolation?
Ignoring the historical baggage, the fact that skins can visually lie about how much of a circle is clickable is insane in a rhythm game where aim matters. How is the "necessity of seeing the true clickable radius" ever "debatable"? How hitcircles work and where they accept input is core game mechanics. This "true clickable radius" is layers of complexity that should not ever be there and yet we're here because of historical failings. I want to correct them now as much as it is possible and practical, to a unified model, rather than continue descending this path of madness.
Discard all of your historical expectations for a second. Do you realise how insane this sounds in isolation?
Ignoring the historical baggage, the fact that skins can visually lie about how much of a circle is clickable is insane in a rhythm game where aim matters. How is the "necessity of seeing the true clickable radius" ever "debatable"? How hitcircles work and where they accept input is core game mechanics. This "true clickable radius" is layers of complexity that should not ever be there and yet we're here because of historical failings. I want to correct them now as much as it is possible and practical, to a unified model, rather than continue descending this path of madness.
I actually agree with you on this, in isolation it actually does sound like it'd make no sense and be a terrible idea. However I believe the past has shown that it just didn't cause any major issues, at least for mapping. Why dismiss a tried and tested approach over it being a theoretically bad idea? I think that for players changing the radius to the full clickable area would probably not pose a real problem, but for mappers it causes issues because maps won't look the same on stable and lazer.
I think the bigger issue is that lazer has introduced 3 different radii for skins (with argon using a different radius for circles & sliders even), throwing any sort of consistency regarding object radius out of the window.
I think the bigger issue is that lazer has introduced 3 different radii for skins (with argon using a different radius for circles & sliders even), throwing any sort of consistency regarding object radius out of the window.
Which is again why I'm more partial to changing those to match the "legacy" one before going on wild excursions wherein all of this is customisable. At least as a start.
I'm not actually interested in debating this one further. I just need @smoogipoo's opinion on the matter so we can enact the change to argon/triangles and that will be all that is required.
I do not care that the argon slider radius doesn't match the blueprint, this is expected and intended and good.
I'm leaning in favour of adjusting skins to match legacy. Also I'll point out the wiki somewhat standardises this: https://osu.ppy.sh/wiki/en/Skinning/osu%21#hit-circles
@minetoblend do you want to give the alternative direction a try (specifically, adjusting argon and triangle skins to use the same radius as stable, alongside the editor blueprints)? if not I'm happy to take it on.
Going to close this PR as the new proposal is completely tangential to what was done here.
Sure, I can give it a shot. For triangles skin this seems straightforward but I'm not entirely sure about argon. Would the circle radius be the one to match or the slider body radius?
Sure, I can give it a shot. For triangles skin this seems straightforward but I'm not entirely sure about argon. Would the circle radius be the one to match or the slider body radius?
I'd make it so the circle radius matches stable and the ratio circle radius/body radius stays the same. That would mean slightly reducing body radius if you decrease the circle radius.
For the selection blueprints I'd make the circle radius and body radius exactly match the radii in legacy skins.