Subfolders "Cheats" / "Mods" / "System" to manage contents directory?

[Clydefrosch22]

Feature Request

What feature are you suggesting?

Overview:

The titles/contents folder was never very organized, but with more and more cheats and mods available, it becomes a horrorshow to manage. That's mostly due to the nonspeaking titleid nature of the folder names, but I assume there's a good reason why it's like that and has to stay like that.

I'd take any way to organize this better to be honest, subfolders, even if its just two hardcoded ones for Cheats and Mods (to prevent scanning every titleid folder for a potential further titleid folder inside), are just the best I could come up with to bring a little order into it.

Nature of Request:

• Change

What component do you feel this would best fit within?

No idea.

Why would this feature be useful?

Because the contents directory can easily become a hard and confusing beast to tame. If you're on and off with messing with your system, it's easy to lose track of what mods you installed to what games, which folders are important because atmosphere needs them and once you throw in a few cheats (or the entire pack), everything mingled together, there's not much to do to than painstakingly opening every folder/checking all the ids, or throwing everything out indiscriminately and starting from scratch.

Having a few more speaking foldernames may or may not also cut down a little on 'where do i put the mod/cheat files' questions.

I know messing with directories is always icky and it's really not high priority, but as an option, it would be really helpful if it's at all possible.

[mpql]

I support this feature. In my mind, it'd be incredibly useful to know if something is replacing file system guts in a game vus "layered FS" (or whatever Atmosphere uses?), is a sysmodule, or is a cheats txt.

To add to that a bit, it would be great to separate "user" files versus distributed ones -- e.g. one could copy the Edizon cheats/scripts from the git repo, but have cheats manually put in by themselves in different (sibling) parent directories.

I may even try to contribute to this, but my C is a bit rusty. 😅

[Haevens]

I'm all for this idea of having a mods and cheats folder would be much clearer.

[ajax-47]

This would be a neat addition. Would break our current setup though.

For now I'd suggest using Simple Mod Manager for controlling your mods and patches and whatnot. It will add the files to the atmosphere folder, so just set up each "mod" to install to whatever folder it needs (contents, exefs patches, etc).

If you need stuff installed outside the atmosphere folder, you can edit the Mod Manager's install folder.

Obviously this isn't ideal, but it has helped me immensely for managing this sort of stuff.

[Clydefrosch22]

it wouldn't break anything if these folders were optional.

[Rodmicael]

organization and the main folders and subfolders because unfortunately not and like Wikipedia and I agree that if everything was well organized we would not waste hours reading to add or copy the codes it looks like a forest hahahaha we have to be indian jones to be able to find the holy grail if the motto is difficult then you got it.

[AnalogMan151]

To make the Contents directory contents easier for human reading and management couldn't a feature be added where after the program ID you put a period and then anything after that period is ignored by Atmosphere? So instead of 0100ABF008968000 you would have 0100ABF008968000.Pokemon Sword or 00FF0000636C6BFF.sysclk. Atmosphere would read the folder name and only read up until the first period to get the program ID and ignore the rest. Would let us name our content folders for easy browsing when updating cheat files or mods.

The only issue I see with this is that it would technically allow you to have more than one folder for the same program ID in which case Atmosphere would likely only load the first one it finds alphabetically.

[SciresM]

no.

What I said the last time this was suggested:

No matter what solution we take regarding multi-contents-folder support, atmosphere is never going to allow non-program id folder names (or text after the program id). The complexity overhead is flat out not worth it, it introduces entirely new classes of error case bullshit (like two or more folders with the same program id).

It turns a simple one way mapping via string format into an ambiguous operation that requires a full directory scan.

Not happening.

[micah686]

What if there were statically defined folder names, such as system, sysmodule, user, where there was only a minimal amount (~2-5) folder names. Then, Atmosphere could have hardcoded paths to load any system titles from contents/system/00..., sysmodules from contents/sysmodules/00... and user-defined mods from contents/user/00.... With this approach, it could be so that if someone put modified files in the wrong folder, Atmosphere wouldn't even look at it to load. So if someone put a Breath of the Wild mod in the contents/system folder, it wouldn't even attempt to look at it.

This way could potentially meet your requirements of no arbitrary folder names/non program id folder names, while providing enough separation of the files so that it is easier to work with the files that you need.

The other potential option I could think of is to define a structure/format/layout of a metadata/information file that would be named <TitleID>.meta that would be placed inside each of the TitleID folders. This would allow homebrew to be created/modified to read from the <TitleID>.meta file and display that information in a way that is helpful to the user. A bonus to this approach would be that the contents folder structure wouldn't have to be modified and causing headaches for the devs of Atmosphere-NX.

[Rodmicael]

Não se vc colocar eles para subir junto cada um com seu diretorio definidos como se fosse na estrutura de arvore.

Em qui., 24 de mar. de 2022 às 00:07, micah686 @.***> escreveu:

What if there were statically defined folder names, such as system, sysmodule, user, where there was only a minimal amount (~2-5) folder names. Then, Atmosphere could have hardcoded paths to load any system titles from contents/system/00..., sysmodules from contents/sysmodules/00... and user-defined mods from contents/user/00.... With this approach, it could be so that if someone put modified files in the wrong folder, Atmosphere wouldn't even look at it to load. So if someone put a Breath of the Wild mod in the contents/system folder, it wouldn't even attempt to look at it.

This way could potentially meet your requirements of no arbitrary folder names/non program id folder names, while providing enough separation of the files so that it is easier to work with the files that you need.

The other potential option I could think of is to define a structure/format/layout of a metadata/information file that would be named

.meta that would be placed inside each of the TitleID folders. This would allow homebrew to be created/modified to read from the meta file and display that information in a way that is helpful to the user. A bonus to this approach would be that the contents folder structure wouldn't have to be modified and causing headaches for the devs of Atmosphere-NX. — Reply to this email directly, view it on GitHub , or unsubscribe . You are receiving this because you commented.Message ID: ***@***.***>

[ruje0504]

I would like to join yuzu's romfs_ Ext, to patch the file with ips

[SciresM]

Yuzu's romfs_ext stuff is explicitly not being added to atmosphere, per discussions with yuzu developers about how and why it's bad.

[ruje0504]

Yuzu's romfs_ext stuff is explicitly not being added to atmosphere, per discussions with yuzu developers about how and why it's bad.

Thank you for your reply. I have some trouble when i patch some large files. I'm looking for another way. Have a good day