-
Notifications
You must be signed in to change notification settings - Fork 286
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FR] Enhance HDD configuration location #358
Comments
what about adding a new config: and what about adding a mesage if the HDD partition doesnt exist?? allowing the user to choose the partition size (instead of creating +OPL @128 Mb without asking) |
That's what he suggested in other words. It's a good idea, because a standard-format of the HDD includes "__common". I think the best solution would be to have support for an OPL CFG in there, but let it "fall back" to +OPL, once it doesn't find a config there. I suppose that might even be only a line for the lookup-path to add, hence (if I'm correct) a matter of seconds to implement. Regarding the size-choice. |
yes! but instead of writing the partition name, choose between fixed options. |
There can be many options that can be done "by accident" I don't think that we should rely on it. The user can delete "by accident" memory card folder which contains opl settings and so what? Should we keep that folder protected or hide it, or do some user protection for it? I don't think that this can be a reason for not using it for storing configuration. __sysconf used for storing HDD OSD supported files and system drivers. FHDB can be treated as a system driver as well - this is why it is stored there. OPL isn't a system driver - it is an app. @TnA-Plastic you want to add also some fancy GUI option with user-selectable options? It will be cool but it will require a lot of work. As for now I just advise storing the partition name inside some config file and that's all. If there is no such file it will use __common/OPL. As about size, maybe we can add size inside config file. |
@AKuHAK Basically when hdd is init it checks __common for an OPL folder, then if PP.OPL partition exists, then if +OPL partition exists.. if all fail a window pops up asking where you wanna make your opl part (up and down to cycle through the 3 selections) Then upon save, stores it in your opl cfg to know which to mount at next boot. I've only been able to test on pcsx2. Additionally could add a gui option if people have multiple opl parts (for some reason?) and want to change which one they're using without having to delete cfgs or partitions. Edit: pushed some changes. |
I did a quick review: looks very promising. Some notes: All OPL filesystems use the root folder by default. I hope that using By the way, subfolder support will be good stuff for USB too. I really don't like all these folders (DVD, CD, CHEATS, etc) at the root of my USB. One more thing. Didn't quite understand from the code how it will handle already created partitions if we try to choose one. As I understand your logic now is such: The problem is - where is saved this config? If it will be saved on a custom location, how opl will know on the next boot where to get it? For example, if only 1 HDD is attached to ps2, no USB, no memory cards, nothing except hdd, then opl will ask for creating new partition every time on boot. My idea was, that |
what about skipping __common completely? |
I like the idea of a sub folder for every partition and even USB but because it’s been used the old way for so long if we change it now it will break compat for lots of people so I’d rather just leave it.
Yea that’s correct, the config is saved on your newly created partition (or folder in __commons case) manually by selecting “Save Changes” in the menu. If it is the only device connected, then on next boot gOPLPartition is default to +OPL (since that’s what it has been for years) so it checks there first then the others, so you won’t be asked to make a partition every time. If one already exists it will be found. P.S excuse my use of the code brackets here I can’t find the quote button on my phone :-P |
Yea it might be better to just skip __common, it brings a lot more complications than just using PP.OPL & +OPL.. wouldn’t have to worry about different prefixes or folders.. code would be cleaner too.. I’ll make some changes when I can. 👍 |
But if you skip the __common partition you will loose the main goal: saving hdd space. PP.OPL or +OPL both are 128Mb. I agree that PP.OPL is better than +OPL for those who are using HDD OSD cause they will save 1 partition. But for others it is still wasting of space, this is why I advice to move default location to the __common/OPL Regarding pfs it is seems that you misunderstand the pfs logic. So you call filexiomount function, then you open pfs0. But you cannot be sure that filexiomount will mount exactly pfs0. Filexiomount will mount the lowest possible partition. So if pfs0 is taken it will mount pfs1, if pfs0and pfs1 are taken itwill mount pfs3. You cannot be sure that there were no filexiomount calls before your function called it. So it will be much safer to umount pfs0 each time you try to mount it (not only in the end). |
Fair point.
I'm not sure I explained what I meant very well. "Sure no problem." means Yes I can do that :-P. When OPL is doing things like making folders etc it uses the variable hddPrefix which is fine when everything is being done on root but when I've made some changes (keeping __common) KrahJohlito@edc62c4 Unmounting |
fixed in #423 |
Is your feature request related to a problem? Please describe.
For now, OPL is creating partition "+OPL" on launch. First of all it is wastingof free space on hdd (128 Mb). And maybe someone wants to use different location for storing configuration.
Describe the solution you'd like
Maybe it will be useful to move configuration into "__common/OPL"? For those who still want to use old "+OPL" maybe can be used some file inside "__common/OPL" which contains alternate partition name.
Personally, I am using " PP.OPL" partition to make it visible through HDD Browser as well.
The fix can be implemented really easy, but I dont know maybe I missed aomething.
The text was updated successfully, but these errors were encountered: