Various editor shortcomings

[DeviousPanda]

A BN's perspective for modding on the lazer editor

(im sorry if my formatting is bad or anything else related to that is hard to read, i have no experience with using github or game dev)

these were the issues i found from trying to mod a mapset on lazer, with the goal making sure that mapset is rankable

• [x] no way to check for offscreen objects (even if there will be a need for this or not in lazer) (loosely related to #11202)

• [x] no access to AiMod or third party modding tools (although im sure you are already working on these) (https://github.com/ppy/osu/issues/12091)

• [x] currently the timeline itself feels really confusing visually, as objects do not touch the snapping ticks (apart from every 4/1 bar), also as the timeline both at the top and bottom of the screen are solid colour it feels a bit cramped, this means that maps with complex snapping are almost impossible to make sense of (comparison of lazer and stable) (https://github.com/ppy/osu/pull/12078) the stable editor makes it much clearer what the notes are snapped to as the notes rest within the timing ticks themselves

• [x] with complex snapping there also isnt the same option as in stable to select more complex snapping, although that is already opened here https://github.com/ppy/osu/issues/2316

• [x] highlighting sliderends on the timeline is very awkward due to the selectable window being a few pixels apart (https://github.com/ppy/osu/issues/12092)

• [x] cant mod hitsounds such as sliderslides/sliderticks or hitsounds on sliderends because they do not have any interactable hitbox specifically, examples on stable currently (these specific selections are acheived by double clicking the sliderend or body in stable, and in lazer this doesnt do anything rn)

• [x] timestamps cant be copied in lazer - you cannot timestamp notes so modding is essentially impossible right now (https://github.com/ppy/osu/issues/12028)

• [x] no access to the map file from the editor (https://github.com/ppy/osu/issues/12029)

• [x] no metadata access apart from a few basics like song name in the setup screen (no tags, epilepsy warning, stack leniency, unicode artist/song name title etc), as metadata is such a big part of rankability for a mapset this is a big issue, examples of stable vs lazer:

• [x] no way to tell if the mapset is the most up to date version as you cannot update the map ingame, which can be an issue when modding as there is no way to tell if the mapset you are modding is the most recent version

• [x] hitanimations are non-toggleable so its harder to see overarching patterns within the editor

• [x] the timing editor feels unfinished (would like to know if thats the case or not), as a further explanation of this point the new timing screen feels really cluttered with little info on each point without clicking on it directly (lazer compared to stable)

• [x] also as a side note for the timing panel, seems like the speed multipliers have rounding errors

• [x] you cannot change hitsound sampleset for specific objects (drum normal soft etc)

• [x] you cant use a different sampleset for hitsound additions (say normal base with a soft clap), this is pretty essential in hitsounding maps as placing a new green line every time you want to change the main sampleset would make hitsounding much slower, (this menu implemented into lazer would fix that)

• [x] you cannot see the hitsounds being used (sampleset) without going into the timing menu specifically (as the screenshot above shows when you highlight a specific object it shows the base sampleset of the hitnormal plus the sampleset used for the additions - this distinction between sampleset used for base and additions isnt present in lazer right now

• [x] cannot view slider velocity changes or hitsound volumes without specifically hovering the labels on the timing screen. (relating to my post of the timing panel earlier and improving visual clarity so you dont need to click on every green line to see its info)

• [x] no customisable timing signature changes (5/4 etc) lazer compared to stable

• [x] no manually adjustable playback rate (25% also isnt here) (https://github.com/ppy/osu/issues/2393)

• [x] as the editor field is so small - there is a much bigger disconnect between editor and actually playing a map which can give a different impression on how a map could be modded etc (for example circle size is drastically different from editing to playing, also while i am no design expert, the editor feels way more cluttered than before, some way to toggle on and off extra clutter (such as HUD scaling or adjustable HUD opacity would be greatly aprecieated) comparison of clutter from stable to lazer again on this point - i think the clutter complaint i have mainly stems from the active playfield in the editor being much smaller than on stable

• [ ] clicking on the song file name doesnt bring you to the map file, it just opens your computer files clicking on this just brings me to my files and not to the map file

• [ ] a lot of maps are hitsounded with default samples, the introduction of the new sampleset makes a lot of these sound completely broken/wrong - a way to fix this would be to have a toggle option in the song setup page that you can switch a map between stable and lazer default hitsound samples (that by default is toggled on for maps made before lazer map submission is released possibly?)

these are just a few issues i found when checking the editor for like 30mins - im sure if alot more bns were to check (some alot more competent at actual game dev) then you would be able to get a much better picture of what is currently lacking between stable editor and lazer editor

final thoughts: right now modding is basically impossible on the new editor, and from my experience with using it here i would much rather prefer to map/mod on the stable editor

[peppy]

cannot view slider velocity changes or hitsound volumes without specifically going to the timing screen and clicking on the specific line

this is shown in the timeline, are you sure you are on the latest version?

no manually adjustable playback rate (25% also isnt here)

this is available in the bottom right. can you explain what you mean? in addition, 25% playback was removed because it destroys the audio. maybe we can add it back with silenced audio track though.

clicking on the song file name doesnt bring you to the map file, it just opens your computer files

I have no idea what this means.

In general, I recommend you try and split these issues up into individual reports over time, following the template and providing screenshots showing what you mean, as your single sentences are not explaining enough for us to take action in several cases.

[DeviousPanda]

im sorry that im new at this, but what did you mean by this comment then.

"yep! https://github.com/ppy/osu/issues is where you can do this. please make sure to read the issue template and search before posting. generally we try to make one issue per... issue, but for cases like this i'm willing to make an exception if you find it easier to list off all the point in a single issue (myself or someone else will do the splitting out)."

i really do not know how to use github or anything like that so it would be appreciated if someone could help

[bdach]

On github, smaller issues that can be closed one-by-one are preferred to large ones like this, although I do understand not wanting to spam the tracker with like thirty issues at once. That part notwithstanding, we have to understand what you mean in order to be able to act on it. So you might need to clarify some of your points because of that.

In addition to the above clarifying question, I have several ones of my own:

also as the timeline both at the top and bottom of the screen are solid colour it feels a bit cramped

Do you have a suggestion of what could be improved in that regard?

no access to the map file from the editor

Ideally I think the .osu file should not be accessible from the editor, if we can avoid it. Generally internals like that shouldn't be exposed to end users if we can avoid it, hopefully all relevant functionality would be reachable from within the game UI. Is there a particular reason for needing to inspect it?

the timing editor feels unfinished (would like to know if thats the case or not)

This isn't really specific. Why do you think that is the case? What's missing?

[Walavouchey]

25% playback was removed because it destroys the audio. maybe we can add it back with silenced audio track though.

If you mean audio distortion, then yes, that is to be expected when slowing audio down. The primary reason for using 25% playback is to check timing, so muting the audio would be completely useless.

[peppy]

Oh the timing editor is far from usable or finished. It is actually one of my next focuses for the editor.

@DeviousPanda as a starting point, could you edit your initial post to have screenshots or more context for each point, where possible?

@Walavouchey I'm not sure if this was lost in the recent years, but timing at 25% is discouraged and inaccurate. That's a whole different discussion and you probably need to understand how audio works to begin to appreciate that fact, but it stands true. Please don't time at 25%. Again, this is not a discussion for this thread, though.

[DeviousPanda]

no access to the map file from the editor

Ideally I think the .osu file should not be accessible from the editor, if we can avoid it. Generally internals like that shouldn't be exposed to end users if we can avoid it, hopefully all relevant functionality would be reachable from within the game UI. Is there a particular reason for needing to inspect it?

as a bn there are many things we need to make sure every aspect of the map file is rankable

[peppy]

Every aspect of the map should be visible from the editor, for sure. But allowing access to the .osu will be required to allow for any edge cases.

[Nivalyx]

(bdach) Ideally I think the .osu file should not be accessible from the editor, if we can avoid it. Generally internals like that shouldn't be exposed to end users if we can avoid it, hopefully all relevant functionality would be reachable from within the game UI. Is there a particular reason for needing to inspect it?

i'm quite certain that DeviousPanda was -- at the very least -- referring to the "open .osu file via notepad" option that is present in the stable editor but is currently missing in the lazer editor tho.

there are many many many uses of this feature (esp. for experienced mappers) really -- here are some examples of it :

• creating an exact copy a specific slider from one map to another
• applying a combo color scheme in bulk across all difficulties ((it's much more convenient to apply the desired combo color on one diff and then just copy the [Colours] line from that diff across all .osu files instead of using the Song Setup menu again and again))
• copying what's written under the [TimingPoints] line -- and vice versa -- for timing mods ((as demonstrated in this mod post among many other timing mods out there))

[fillsre]

no access to the map file from the editor

Ideally I think the .osu file should not be accessible from the editor, if we can avoid it. Generally internals like that shouldn't be exposed to end users if we can avoid it, hopefully all relevant functionality would be reachable from within the game UI. Is there a particular reason for needing to inspect it?

Access to the .osu file can greatly improve mapping efficiency, for example using time signatures like 13/4, creating slider art easily through editing code, copying sliders or even copy maps over quickly if needed (for example when you are transferring a map to a featured artist beatmap template). Making it harder to access this file will make it harder to perform these actions (especially when it is already a feature).

[Regraz]

(bdach) Ideally I think the .osu file should not be accessible from the editor, if we can avoid it. Generally internals like that shouldn't be exposed to end users if we can avoid it, hopefully all relevant functionality would be reachable from within the game UI. Is there a particular reason for needing to inspect it?

Like you said it is "ideally". I appreciate and agree with that if everything can be accessible in the client there is no need to open the .osu file . But we are talking about the current editor which is far from reaching that objective.

For all the similar issues, having a future objective is never a valid reason to decline any suggestions for mitigating current gap between reality and the future objective.

[bdach]

Well, yes. It should be obvious that there is some ways to go with the current editor, simply by looking at the OP. I hope that it is clear that my intention was to state that I'd hope all the workflows that currently require manual editing can in the future be made easier by in-game operations.

(Although that timing section example does seem to be a pretty hard one to handle cleanly...)

[maotovisk]

I personally think making possible the access of .osu and .osb files as a legacy feature is a must-go considering the current workflow of mappers/storyboarders. I know there are many new planned features that will provide the mapping tools (that we currently have as third party ones) in a ingame user friendly ux, but those features will need at least a new learning curve and probably will take time to show as an usable thing to the mappers. Furthermore, taking into account the "new ux philosophy" (which is a good thing) can be a little annoying to those who are used to the old methods of doing things, which is a thing that you may take into account when asking mappers that are coming from stable to test lazer. As stated above, ideally new methods to do these things we do in a archaic way (hs copying, storyboarding, mapset checking, etc.) will come and when they come i hope people will manage to migrate to them.

[bartflk]

no access to the map file from the editor

Ideally I think the .osu file should not be accessible from the editor, if we can avoid it. Generally internals like that shouldn't be exposed to end users if we can avoid it, hopefully all relevant functionality would be reachable from within the game UI. Is there a particular reason for needing to inspect it?

Access to the .osu file can greatly improve mapping efficiency, for example using time signatures like 13/4, creating slider art easily through editing code, copying sliders or even copy maps over quickly if needed (for example when you are transferring a map to a featured artist beatmap template). Making it harder to access this file will make it harder to perform these actions (especially when it is already a feature).

I agree with this, taking it away will only take away quality of life for people who know how to use it, the granularity it gives you to edit the map is too grand to pass up.

[bdach]

"+1"/"I agree" comments are not necessary, I get the point. Please use reactions instead.

[UndeadCapulet]

picking up for deviouspanda at their approval

cannot view slider velocity changes or hitsound volumes without specifically going to the timing screen and clicking on the specific line

this is shown in the timeline, are you sure you are on the latest version?

panda meant to refer to the timing panel here, with the only way of viewing anything is by hovering like this https://puu.sh/HpNSI/94047f9692.png. compared to https://puu.sh/HpNTF/63597b4b47.png it's way less useful

no manually adjustable playback rate (25% also isnt here)

this is available in the bottom right. can you explain what you mean? in addition, 25% playback was removed because it destroys the audio. maybe we can add it back with silenced audio track though.

bit of a mistype due to a bunch of ppl giving feedback while panda was streaming, this was mostly just another mapper requesting 25% volume. many mappers and bns use it for a variety of reasons, predominantly for snapping, discerning number of notes with the space of a couple whiteticks, etc. yes it distorts audio, but experienced mappers work around that with little issue, if you feel the need you can add a warning about timing but 25% is super useful still

clicking on the song file name doesnt bring you to the map file, it just opens your computer files

I have no idea what this means.

lol understandable, this was a late addition, it was referring to this button in the setup panel: https://puu.sh/HpNXZ/a852f985a6.png when you open a map in the editor this button should redirect by default to the already-selected mp3 in the map folder, but it just routes to the c drive or something

part of the problem with splitting each point into separate issues is that atm there are so many missing features that if we aren't just bulkdropping them all in bulleted lists like how panda did then it becomes extremely hard to keep track of all the posts we've made. it also becomes harder for other mappers to give feedback bc they're expected to check if their points have already been posted, and we all have such long lists that checking for each point is a nightmare, esp since most mappers aren't familiar w/ github, and most won't want to go through it. i very much think just keeping everything contained would be better, but i have some freetime and can do some quick work splitting if you really would prefer it that way

[peppy]

Splitting out issue can be done one at a time (each time you do so, you can link the item on this bulk issue to the linked issue, see https://github.com/ppy/osu/issues/11250 as an example).

It helps allow for follow-up on individual issues to flow well, rather than attempting to have interleaved conversations like we are having right now.

for the clicking on song file: lazer stores files differently, which would make this quite weird to do. what is the intention of clicking on the song file? what would you be looking to do with it from this point?

[UndeadCapulet]

ah that bulktracking w/ links would work yeah (yay i learned something about github)

clicking the audio track button after opening a map would be useful for either switching to a higher quality/ranking criteria-following mp3 file or for relinking a map to a renamed or newly added mp3. most likely in either scenario the mp3 in question would be in the map folder and not at a random location on the user's computer; they could always navigate to the folder they need to anyway (unless we cant get to map folders anymore? whats different about lazer files, would this not work). its also just the generally expected response from clicking on a filename to then be directed to the location of said filename (i think this is why this point was included to begin with).

actually this whole dropdown functions weird rn bc there's no way to close it after opening, but these are both minor issues, when i go do the splitting stuff i'd focus on missing features i think are basically required for the editor to be usable. which i guess i'll start doing now

[LeNitrous]

To put it simply, mappers would want to keep their existing workflow as there is a myriad of community-made tools. We can also integrate them to lazer later on but it would also satisfy the community FWIW in the meantime is to cater legacy options such as exporting it back to legacy file types like .osu and .osb.

[peppy]

.osu and .osb are of course required. the issue here was specifically talking about the audio track so that confused me. either way, we will provide ways to access the files, and potentially a way to export to a folder for manual editing. for reference, do most of the tools work using copy-paste of code, or drag drop / working on files directly?

[LeNitrous]

The most popular tool is Mapping Tools (on GitHub) and it primarily looks for beatmaps in stable's Songs folder but you can manually load in .osu files. I don't personally use the tools myself so it would be better if someone more knowledgeable about it would provide more information on how it works.

[UndeadCapulet]

drag/drop mp3 into the audio track field works, same for background (tho weirdly when i dragged a background into the compose field it accepted it but only loaded it when i exited to song select). copypasting objects seems to work, at least from my quick tests

[bdach]

@UndeadCapulet:

unless we cant get to map folders anymore? whats different about lazer files, would this not work

To touch on this, map folders are indeed not currently readily available in lazer. Here's a wiki article explaining why.

[peppy]

highlighting sliderends on the timeline is very awkward due to the selectable window being a few pixels apart

are you meaning for sample changing of the slider end here?

[DeviousPanda]

highlighting sliderends on the timeline is very awkward due to the selectable window being a few pixels apart

are you meaning for sample changing of the slider end here?

i mean being able to drag the sliderends out to repeats

also i changed each point to a checkbox as per vinxis' request on my main post, and have updated all the points with deeper explanations and screenshots to explain my points better

[NoffyNoffeh]

Regarding the mentioned clutter issue and the playfield feeling small, there IS ui scaling available, however it affects everything in lazer globally. If I set it small enough to where the main compose tab feels comfortable, a lot of things such as the timing tab end up tiny and hard to read. So it feels like this is more a proportions issue than just scaling.

[peppy]

For the tick visibility issue, how does this feel?

[NoffyNoffeh]

Way way way better. I do wonder if the circles themselves could have a small vertical line attached behind them, so we can see if they're centered even better than on stable? What do others think of that?

[peppy]

As an aside, this issue thread is nigh impossible for me to work with, especially now with the checkboxes present. I won't be replying further in here to avoid everyone going insane.

I would recommend that each of the remaining issues is spit out into its own, and the checkbox is filled once that is done. This issue can be closed once each reported issue is tracked in a better way.

[DeviousPanda]

As an aside, this issue thread is nigh impossible for me to work with, especially now with the checkboxes present. I won't be replying further in here to avoid everyone going insane.

I would recommend that each of the remaining issues is spit out into its own, and the checkbox is filled once that is done. This issue can be closed once each reported issue is tracked in a better way.

I can split each issue out to its own post like you suggested in a few hours

[peppy]

I guess splitting out issues was forgotten about? I have so many questions about each point but it's not possible to follow up in this thread.

I'll revisit the issues pointed out in here as they are split out into new issues, so the ones which aren't will not receive priority for the time being.