1. The installer must be changed to when copying files to dev_flahs copy also to the data dir in the game dir.
2. Rebuild the tollkit/sdk to have to title IDs, one for the installer, other for the game data
3. The themepacks are a problem, because when you install them they need to go to the data dir.
One workaround i see is the title ID of the data be XMBMPDATA and so the installer (installed in XMBMANPLS) would copy all xmbm+ to /dev_hdd0/game/XMBMPDATA and the themepacks would install also to /dev_hdd0/game/XMBMPDATA because they would have XMBMPDATA title ID.
One minor issue is when you remove the theme data (gameData) it will remove all the XMBM+, so in the following scenario you will have the same problem:
1. User install the installer/switcher
2. User runs the installer and install the XMBM+
3. User removes tthe installer/switcher
4. User installs a theme pack
5. User removes the themepack
This way the user will not have a install package option and have to reinstall firmware (soft-problem).
In other words everytime the user removes a themepack will not have a install package option
Of course, as i say the installer/switcher SHOULD NOT be removed, so for me is a minor issue and due to user misuse.
Also this can be resolved also if the themes are installed in other directory like for instace XMBMPTHEM.
If the user removes the installer and the theme pack the xmls will be there. the only problem will be lack of images that the user can put again just by installing the themepack
Waht do you think?
I think is the good way ... to create folder XMBMPDATA and XMBMPTHEM this will resolve the problem !!
other think i have try to readd the old string that work in the past for the problem 3 but that doesn work !! do you know why (i have use the string in the v0.50 because i remember in this version this option work)
EDIT:
WOW i am First for the 100 pages post !! I Win Something ?? LOL
Last edited by XiorgON; 09-17-2012 at 08:41 AM.
THE KEY OF THIS WORLD IS THE HUMAN**THE LOCK OF THIS WORLD IS THE STUPIDITY OF THE HUMANITY**<==>**CHANGE YOUR WORLD**<---->**FUTURE IS NOW
Is there some way you can install a pkg, from within an application? If you can, installing an empty 'Game Data' title with a different ID to the installer app would create a location to install the XML files. And allows the user to delete the installer afterwards.
Originally Posted by andreus
@ps3hen, no i don't know any method and didn't see that working in any homebrew.
In showtime and multimen they update by replaced SELFs not pkg.
even if you can create all pkg dir structure in /dev_hdd0/game dir it will not work brcause it need to be in XMB Database too.
I think when a pks is instaled the files are copied to game dir and an entry is added to the XMB Database. that dabase is (i think_) in /dev_hdd0/mms/db/*, if you hex view that files you will see that
so until someone finds a way to change the xmb database from a homebrew that is not possible.
Altough could be possible to have an option in the installer that just replace the files in the directory
There is a way to generate "game data" folders from inside a game (or homebrew of course). The first game i just remember it does is gran turismo 5 (it stores "ghost laps" as "game data") but i dont know any hombrew that does it
I imagine the game can send some syscall/arguments to generate the content. This way the XMB database is updated correctly
Is something similar than how "game saves" are generated (by the game itself)... the only notable difference is are different content types (different CATEGORY)
Also, im not sure how all the folders that belongs to a game are "linked" to the game itself... iirc... is by the names of the folder (maybe there is something more working as another database)... but basically, the names of the generated folders are "derivated" of the main game
This "standard" keeping the same names maybe is not needed because a homebrew can load files fron other paths so is only something to be aware when generating the content
e.g: a game BLUS12345... can generate "game saves" with names BLUS12345-profile BLUS12345SAV, etc... and with "game data" i dont remember wich names are valid, but by default is the same name than the game BLUS12345
But like i said, i think there is nothing documented about all this
--------------------
The idea of using different "game data" i think is good. When installing to dev_flash there will be always problems because all kind of XMB contents can be uninstalled by the user (this is good)... so there will be always a chance for the user to make a wrong uninstall
But one important thing is in "game data" you can use SUB_TITLE (inside PARAM.SFO)... with this you can add A LOT of text lines under the TITLE text line to advise the user how to uninstall... this texts are clearly visibles, you can use them to avoid mistakes (or to explain what this folder contains)
Originally Posted by andreus
Another idea is when installing to create a /dev_hdd0/game/XMBMANPLS_DATA directory and copy the XMBM+ files to there, this way with a uninstall will only remove the
Originally Posted by andreus
/dev_hdd0/game/XMBMANPLS directory and the XMBMANPLS_DATA would stay there so the XMBM+ would not be removed so no soft brick .
I think this folder will be "found" when using the option "rebuild database" (from recovery menu)... identifyed as a non-standard content... then moved to the folder "lost+found"
Im not sure of the result... but "rebuild database" will find it
why i choose XMB manager plus in XMB manager plus v1.00RC7 the install time took so long (over 7 minutes.) ? while on XMB manager plus v0.60 the install time only 2 minute ? i'm on Rogero CEX3.55 v3.6
why i choose XMB manager plus in XMB manager plus v1.00RC7 the install time took so long (over 7 minutes.) ? while on XMB manager plus v0.60 the install time only 2 minute ? i'm on Rogero CEX3.55 v3.6
Hi they have many reason why the install time is more longer
1- Is RC version (release candidate) not Final Version
2- The code have many change and use different internal process
3- The installator is not the same like Rebug manager installator (More sys check in the XMBM Installator)
Possibly other reason like: CFW you are using
THE KEY OF THIS WORLD IS THE HUMAN**THE LOCK OF THIS WORLD IS THE STUPIDITY OF THE HUMANITY**<==>**CHANGE YOUR WORLD**<---->**FUTURE IS NOW
Hi they have many reason why the install time is more longer
1- Is RC version (release candidate) not Final Version
2- The code have many change and use different internal process
3- The installator is not the same like Rebug manager installator (More sys check in the XMBM Installator)
Possibly other reason like: CFW you are using
Thanks. I've tried XMB manager plus v1.00 the install time as same as v1.00RC7. I like MB manager plus v1.00 because the menu to choose is display at full screen not like XMB manager plus v0.60. Could you fix the install time ?
Thanks. I've tried XMB manager plus v1.00 the install time as same as v1.00RC7. I like MB manager plus v1.00 because the menu to choose is display at full screen not like XMB manager plus v0.60. Could you fix the install time ?
XMB Manager Plus now stores the languages texts in the rco files (that are big!) so it takes a lot to copy them.
This change was made for XMBM+ auto-recognize your ps3 system language without the need to install language packs.
So the time taken really depends on your ps3 and usb drive read and write speed.
For what i know there is not possible to write to dev_blind in 3.6+ DEX systems so the xmbm+ installer would not work.
I never tried, maybe someone found a way by now.
Sorry for the late replies but have other issues in "real" life to care
XMB Manager Plus now stores the languages texts in the rco files (that are big!) so it takes a lot to copy them.
This change was made for XMBM+ auto-recognize your ps3 system language without the need to install language packs.
So the time taken really depends on your ps3 and usb drive read and write speed.
thanks. OK i'll stick with 0.60 version cause install time is short and simple. the reason i like 1.00 cause the screen menu display at fullscreen not any else.