Closed hyperbx closed 12 months ago
Added a blocked label to further indicate the the PR can not be merged at the moment.
As @thesupersonic16 has mentioned regarding an Origins code, I do think that a lot of single code sub-categories are kind of, unnecessary. This is extrapolated in games with more codes. Whilst it works for future proofing, we also don't really have to future proof as its not like the codes can't be moved into a sub category of a main category later down the line. Things like Post-processing
, Skills
and Voice
here feel completely unnecessary, with each containing a single code and just more hoops for the end user to jump through to get to the code they would like to use.
As @thesupersonic16 has mentioned regarding an Origins code, I do think that a lot of single code sub-categories are kind of, unnecessary. This is extrapolated in games with more codes. Whilst it works for future proofing, we also don't really have to future proof as its not like the codes can't be moved into a sub category of a main category later down the line. Things like
Post-processing
,Skills
andVoice
here feel completely unnecessary, with each containing a single code and just more hoops for the end user to jump through to get to the code they would like to use.
Ah didn't realise there being that many Audio
codes, but yeah subcategories with only one code seems unnecessary, maybe we could consider the UI to ignore them? Assuming it doesn't already.
Ah didn't realise there being that many
Audio
codes, but yeah subcategories with only one code seems unnecessary, maybe we could consider the UI to ignore them? Assuming it doesn't already.
Well, that's not a really a solution either, as there are cases where that single code should fall into a sub-category, such as here:
However in my previous example its not particularly necessary to make individual sub-category for those 3 codes and could just fall into the main Audio
category. Once more codes like them are made that would fit that sub-category they can be moved to a sub-category, as that point it would actually make sense.
Agreed with all statements above, the Audio/Post-processing
, Audio/Skills
and Audio/Voice
categories were a last minute addition to keep consistency between games. I'll revert these to prevent unnecessary nesting.
As for subcategories that are character-specific, those will remain as such.
I am not a fan of the Item
categories, at a glance, they do not make any sense to me as my mind thinks of objects in a stage, not that you froze the boost to 100%. I get boost and rings can be gained by items, but when used as unlimited/frozen I don't think they are items anymore especially since its held by the Player.
Agreed with all statements above, the
Audio/Post-processing
,Audio/Skills
andAudio/Voice
categories were a last minute addition to keep consistency between games. I'll revert these to prevent unnecessary nesting.
Some other places where nesting feels unnecessary to me:
Sonic Colours Ultimate/Cheats/Items
Sonic Colours Ultimate/Cheats/Player
Sonic Colours Ultimate/Cheats/Skills
Sonic Colours Ultimate/Gameplay/Objects
Sonic Forces/Cheats/Skills
Sonic Frontiers/Cheats/Objects
Sonic Frontiers/Cheats/Player
Sonic Frontiers/Enemy/Boss
Sonic Frontiers/Fixes/Camera/Photo Mode
Sonic Frontiers/Fixes/Physics
Sonic Frontiers/Gameplay/Open Zone/Event
Sonic Generations/Gameplay/Enemy
Sonic Generations/Gameplay/Event
Sonic Lost World/Audio/Music
Sonic Origins/UI/Frontend
Something that could be an idea is keeping the codes found in these folders in the folders but removing the sub-category (for now) from the respective codes. That would mean less nesting on the frontend but still got the categories laid out going into the future if and when that becomes necessary to use.
I am not a fan of the
Item
categories, at a glance, they do not make any sense to me as my mind thinks of objects in a stage, not that you froze the boost to 100%. I get boost and rings can be gained by items, but when used as unlimited/frozen I don't think they are items anymore especially since its held by the Player.
Yeah, I agree with this, codes such as Sonic Forces/Cheats/Items/Disable Boost Drain.hmm
, Sonic Forces/Cheats/Items/Disable Ring Loss from Damage.hmm
, Sonic Forces/Cheats/Items/Disable Ring Loss from Super Sonic.hmm
don't sit right with me under an Items
category.
Yeah, I wasn't completely sure on where to put those to be honest, so I lumped them in with being "Items". Do we agree to move boost and Super form related codes to the "Player" subcategory?
Sounds good to me.
Yeah I agree the two (and maybe others too) should be in Player
Regarding the Items
and Player
categories found in many of the games that we have Cheats
for, I feel like there's a bit of a confusion on what those categories should mean.
Codes such as Sonic Forces/Cheats/Items/Disable Wispon Boundaries.hmm
feels a bit misguided in Items
category as that to me implies physical, in the world collectibles as opposed to interacting with inherent game mechanics, such as where the wispon is usable or not, thus it feels like it would fall into the Player
sub-category.
Codes that do feel fit for the Items
sub-category are codes such as Sonic Frontiers/Cheats/Items/Keep Red Rings on Death
as it applies to how the item is found in the Cyber Space levels themselves.
Bottom line is, cheat codes affecting mechanics, such as the player's ring counter, boost, life count, etc. should be categorized under Cheats/Player
, whilst codes affecting how the physical object found in the game as an interactable behaves would belong under Cheats/Items
To prevent further unnecessary nesting, we could also just drop the Items
subcategory and move everything to Player
instead - would avoid any confusion later down the line, both to end-users and code developers on where things belong.
That solution is also fine with me (especially since once that ideology is applied I think there would be only 2-3 codes fit for Items
category to begin with).
Hedge Mod Manager 7.12 is out now, so that is no longer blocking this PR.
Since I don't have time (due to personal matters) atm to personally go through the PR to re-review and approve/request changes I'll do some management related stuff regarding this PR.
The codes for the PR should be reviewed as the following: @thesupersonic16
@Sajidur78
@blueskythlikesclouds
Please look for any unnecessary nesting or straight up wrong categories and approve or request changes to the codes for each game. Frontiers can be seen as approved by @HyperBE32 seeing as he is the main maintainer of those codes but if you wish to you can go through those too.
This PR updates the categories for all codes, where necessary, to move them into new subcategories to organise things better in their parent categories.
This PR depends on https://github.com/hedge-dev/HedgeModManager/pull/1 being merged, as well as a new HMM release being made to ensure this change is met across all versions of the mod manager.Feedback on these subcategories is very much appreciated in the meantime.