We should/could delete this rule, because shouldn't the program know what valid options for all settings in a .osu and give a error/warning if someone try to do something cute like AR12 or some such nonsense. This could be automatically checked for when people upload files.
forum
Do not manually edit anything in an .osu file
posted
Total Posts
23
The only reason you would need to edit your osu file is to either edit a diff specific SB, fix a slider (end) when it goes over (ends) on an uninherited timing section, change the video offset in smaller intervals or to make lead in/preview points have better numbers. I can't really think of anything else right now that would need changing through the .osu file, and this rule prevents some really weird stuff that is possible to be missed (circle size 2, there is actually a ranked map with it 
).
Those stuff I mentioned are exceptions already so I don't really see any problem.
).Those stuff I mentioned are exceptions already so I don't really see any problem.
there are ranked with CS 0 and 1 as well....
Anyway, you missed the offset calibration via-osu: Sometime Offset become 121,9667 for example, and as so it'll be different from diff to diff and you'll need to manually edit.
Anyway, you missed the offset calibration via-osu: Sometime Offset become 121,9667 for example, and as so it'll be different from diff to diff and you'll need to manually edit.
Reasons to edit:lolcubes wrote:
The only reason you would need to edit your osu file is to either edit a diff specific SB, fix a slider (end) when it goes over (ends) on an uninherited timing section, change the video offset in smaller intervals or to make lead in/preview points have better numbers. I can't really think of anything else right now that would need changing through the .osu file, and this rule prevents some really weird stuff that is possible to be missed (circle size 2, there is actually a ranked map with it
Those stuff I mentioned are exceptions already so I don't really see any problem.
Storyboard
beatmap specific skin overrides
Linear/catmull sliders
Reasons that are possible in the editor, but are much easier in notepad:
Slider End
1/9 or 1/5 snap
Move circles/slider nodes by 1 pixel
metadata
video offset
mass edit timing
non-silly slider velocity
fix offset to be integer
fix bpm
bypass editor limits (what we really want to stop, and AIBAT/AIMOD should check for these rather than change them to legal values by default)
This rule is impossible to enforce. We don't ban the method, we ban the end result.
Yeah you do have a point. How about changing the rule so it only covers stuff that shouldn't be changed?
Topic Starter
Well the original rule is longer but couldn't fit. My original point is the program should detect unauthorized changes and give a warning we don't need to clutter rules with something that can be detected automatically
It's really only circle size and stack leniency. Even then, I don't really care, or think having them set to 0 is a problem. If your circles are really big, that means the map is that much easier. If the stack leniency is 0, and you never stack, or only stack on 1/1 or 1/2 notes (slow songs), what's the point? the reason the editor limit exists is because it will be abused. Anyone smart enough to open up notepad and change it is smart enough to know when to use it and when not to use it.
This doesn't require editing the .osu. It is possible to do in the editor.lolcubes wrote:
The only reason you would need to edit your osu file is to either edit a diff specific SB
\:D/lolcubes wrote:
(circle size 2, there is actually a ranked map with it
And I think the rules says "anything that changes the gameplay", which basically is enough to cover what was listed.
If you want any clean SB, you will need to edit it so you avoid silly decimal values. Probably not necessary, but still a nice thing to do, especially if you want to re-use the values you had before.Odaril wrote:
This doesn't require editing the .osu. It is possible to do in the editor.
In any case ziin summed up stuff pretty nicely and I agree with most of it. This rule should probably just go away and the common sense can cover everything else pretty much.
I see this as being unnecessary as a rule. If editing the .osu file causes issues, please report such issues as a bug.
Do not manually edit an .osu file to obtain settings that are disabled within the editor. They're disabled for an actual reason.The reason needs to be explained better... anyway... It's like "you cannot use AR11,TickRate 0 and so..."
Topic Starter
Well the original idea was so that people didn't do weird stuff like AR11 or CS 0 but I think that can be dealt with in mods. Like Ziin said if they know its there they are more likely to use it responsiblypeppy wrote:
I see this as being unnecessary as a rule. If editing the .osu file causes issues, please report such issues as a bug.
Well, if there is to be some manual editing within reasonable [and playable] specs, then it shouldn't be too much of an issue unless it might cause some form of instability. I remember it wasn't a good idea to edit the .osu file to use non-standard inherited timing settings since it caused some bugs to appear. Seeing how the coding is better than it was a few years ago, it makes more choices of settings possible, but best to stick with what is normally given if you don't know what you're really doing or wait until something is implemented to make those settings more stable. But, the main thing is that the .osu file shouldn't be edited in such a way that would cause the map to be unrankable. That's just my thoughts on it though.
Just change aimod/bat to check for out of range difficulty settings and stack settings. That's all that is needed here. I can't think of anything else that will cause it to be unrankable.whymeman wrote:
Well, if there is to be some manual editing within reasonable [and playable] specs, then it shouldn't be too much of an issue unless it might cause some form of instability. I remember it wasn't a good idea to edit the .osu file to use non-standard inherited timing settings since it caused some bugs to appear. Seeing how the coding is better than it was a few years ago, it makes more choices of settings possible, but best to stick with what is normally given if you don't know what you're really doing or wait until something is implemented to make those settings more stable. But, the main thing is that the .osu file shouldn't be edited in such a way that would cause the map to be unrankable. That's just my thoughts on it though.
I have changed my views. This view is outdated. The guideline at the end of this post is not.
Edit:
On an unrelated term: I was thinking about a possible guideline concerning editing the .osu.
Those who wish to edit the .osu for any reason other than difficulty specific storyboarding should know what they are doing. It is very easy to corrupt your beatmap with the wrong edits.
SPOILER
I wouldn't toss the "edit the aimod" reason around too lightly. These rules are being designed according to the game's current limitations. It will take time to rally ideas on what aimod should/should not bring up and then those ideas need time to be coded into the game. If we're just starting to suggest these ideas, then it will likely be many months before the official build sees those changes and by that time the rules may already become canon.
I find this rule ambiguous and tightly covers most opportunities to create opportunities through the .osu. However I have one real complaint. It's concerning circle size selection in the editor.
I think that really the only not accessible setting that I'm aware of that should be allowed is larger circle sizes. I mean I don't understand the current settings for circle sizes. The size for Normal is too small for me in most cases (I use windowed mode). I just checked the circle size for 10 different Normal modes from various songs and none of them use CS 5 (The one stated for Normal).
IMO there's not enough useful circle sizes to choose from in the editor. The lowest circle size obtainable in the editor is 3, that's one size less than what 80 percent of Normal difficulties use, which is CS4. Also the small ones are practically unrankable and as such noone uses them.
If this rule is going to be enforced, I think the modders deserve to have access toCS1(cs1 is actually ridiculously big) or CS2, and CS7 gets removed from the selection in the editor and made unrankable, because there is no rankable purpose for that size.
The spread would be as such
Easy
CS2 CS3
Normal
CS4
Hard
CS5 CS6
CS2 is more rankable than CS7.
If this is covered in the rule, I can't see any other reason why the rule can't just stay a rule. Most game changing elements in the .osu are unrankable if changed through the editor anyways. Slider end snapping could be another exception to this rule. Multi-BPM maps can be a pain for slider transitions. If the .osu allows the slider to be correctly snapped to a timing section that cannot be placed on the proper metronome, then I'm all for it.
I find this rule ambiguous and tightly covers most opportunities to create opportunities through the .osu. However I have one real complaint. It's concerning circle size selection in the editor.
I think that really the only not accessible setting that I'm aware of that should be allowed is larger circle sizes. I mean I don't understand the current settings for circle sizes. The size for Normal is too small for me in most cases (I use windowed mode). I just checked the circle size for 10 different Normal modes from various songs and none of them use CS 5 (The one stated for Normal).
IMO there's not enough useful circle sizes to choose from in the editor. The lowest circle size obtainable in the editor is 3, that's one size less than what 80 percent of Normal difficulties use, which is CS4. Also the small ones are practically unrankable and as such noone uses them.
If this rule is going to be enforced, I think the modders deserve to have access to
The spread would be as such
Easy
CS2 CS3
Normal
CS4
Hard
CS5 CS6
CS2 is more rankable than CS7.
If this is covered in the rule, I can't see any other reason why the rule can't just stay a rule. Most game changing elements in the .osu are unrankable if changed through the editor anyways. Slider end snapping could be another exception to this rule. Multi-BPM maps can be a pain for slider transitions. If the .osu allows the slider to be correctly snapped to a timing section that cannot be placed on the proper metronome, then I'm all for it.
Edit:
On an unrelated term: I was thinking about a possible guideline concerning editing the .osu.
Those who wish to edit the .osu for any reason other than difficulty specific storyboarding should know what they are doing. It is very easy to corrupt your beatmap with the wrong edits.
Topic Starter
TheVileOne wrote:
Those who wish to edit the .osu for any reasonother than difficulty specific storyboardingshould know what they are doing. It is very easy to corrupt and/or make unrankable your beatmap with the wrong edits.
Okay. I did some more thinking and consulted some people and I think the .osu rule is unnecessary. We have existing guidelines that cover all of these issues except a couple.
Stack leniency must not be below 2, and there cannot be a 0 tickrate slider.
Is there really any other reason for this "rule" to exist other than those two things? Having super high ODs, or drain is part of the guidelines. I kind of missed the point that guidelines also cover extremities, such as things that would be unrankable. If the drain is too low, then it will render a map unable to be failed, and if it's too high it would vary. I could not say that without a doubt that a drain rate over 10 would be unplayable in every case, but really all settings should fall under the reasonably playable rule.
So I must admit that this rule is senseless. It's only there to provide an absolute limit when that absolute limit is unnecessary. If we didn't have the rule, then the process could continue normally without any need to state exactly why we need to change the .osu. So I rescind my support for the rule.
Stack leniency must not be below 2, and there cannot be a 0 tickrate slider.
Is there really any other reason for this "rule" to exist other than those two things? Having super high ODs, or drain is part of the guidelines. I kind of missed the point that guidelines also cover extremities, such as things that would be unrankable. If the drain is too low, then it will render a map unable to be failed, and if it's too high it would vary. I could not say that without a doubt that a drain rate over 10 would be unplayable in every case, but really all settings should fall under the reasonably playable rule.
So I must admit that this rule is senseless. It's only there to provide an absolute limit when that absolute limit is unnecessary. If we didn't have the rule, then the process could continue normally without any need to state exactly why we need to change the .osu. So I rescind my support for the rule.
Tick rate is saturated to the 0.5..4 range when loading the map.
I never agreed with having any stacking leniency rules. Unstacked notes themselves should be targeted.
I never agreed with having any stacking leniency rules. Unstacked notes themselves should be targeted.
do you happen to have the stack leniency data? As in the time cutoff between stacks? I hope it doesn't change with BPM...
actually, all these settings would be nice to know. I already know OD cutoffs.
actually, all these settings would be nice to know. I already know OD cutoffs.