Closed yorunoken closed 6 months ago
I could do that for you, if you want ofc. (It's your PR after all)
yeah that's what I thought of doing but I'm kinda busy rn @GabuTheDev, I'll do it in a bit
did you mean something like this?
interface BaseMods {
acronym: string;
}
interface EZ extends BaseMods {
acronym: "EZ";
settings?: {
retries: number;
};
}
interface NF {
acronym: "NF";
}
did you mean something like this?
Exactly. Should be called BaseMod
, and the interface should already have an empty settings
property.
@GabuTheDev the settings
property is only included if there's a non-default setting being applied
if the mod doesn't support settings, it simply won't exist, so it's not a good idea to have that as its property
@GabuTheDev the
settings
property is only included if there's a non-default setting being applied if the mod doesn't support settings, it simply won't exist, so it's not a good idea to have that as its property
My bad. Not so familiar with the osu API. Good to know, thank you!
@GabuTheDev no problem!
actually, you can just pass in a ?
after settings
and it'll be fine, thanks for the recommendation @GabuTheDev
should be ready to merge now
@YoruNoKen Your PR will be reviewed by @cyperdark. This might not be merged directly as ck is working on a new version of this package. It also requires a lot of changes to the files that are using the Mod
interface currently present in main
branch so it might take a while until this change will go live (or maybe I'm wrong, final verdict comes from ck).
@GabuTheDev yea ik I talked with ck prior to making this pr, thanks for the attention :D
also, from what I can see, Mod
is only used to infer a type, so it requires no changes to current files
will be done here https://github.com/cyperdark/osu-api-extended/pull/24
sure :)
Hey there! I suggest making a base interface and extend that for each mod.