ManaGunZ

PS3 ManaGunZ - PS3 Backup Manager by Zar v1.41

it's missing in the code...
It was supporting these covers but not anymore I probably removed these line without paying attention.

As sundungas said managunz also use his own directory to store the covers. You can simple go in global settings of managunz and download them ;)
 
I compile managunz need webp
but build libwebp-0.3.1 get libwebp.a: could not read symbols: File format not recognized
I use 013-webp-0.3.1.sh scripts
how fix it?
 
it's missing in the code...
It was supporting these covers but not anymore I probably removed these line without paying attention.

As sundungas said managunz also use his own directory to store the covers. You can simple go in global settings of managunz and download them ;)
After writing my previous post i was taking a look at MGZ soure code and (as far i understood) it seems there are only 3 paths availables: managunz instalaltion directory, and multiman (2 multiman paths for normal and retro covers)

In my oppinion the removal of dev_hdd0/GAMEZ/covers (inherited from iris) is fine, because that path is not convenient. It made sense when the backup managers only supported PS3 game backups in JB format (with the game stored under GAMES or GAMEZ) but nowadays doesnt makes sense to store in it the covers for other game formats (storing PSP, PS2, PS1, PS3ISO covers inside GAMES/GAMEZ is wrong in concept)

-------------------------
All and all... i dont care about the multiple cover paths, in my oppinion the path inside managunz installation directory is the only priority. And if at some point you decide to remove all the other cover paths im fine with it

But there is something i been trying to convince you since lot of time ago :rolleyes:
I would really, really, really, really, really, really, really, really like if you add a cover path for dev_hdd0/COVERS (located at root of dev_hdd0 and in uppercase)

The problem is everytime i install a new managunz version i use to uninstall the previous, so the covers that was located inside managunz installation directory are deleted :crybaby:
Im very used to this problem but is annoying, the point is the covers should be located in a path externally to managunz because this allows to uninstall managunz and keep the covers

-------------------------
The way i would like to do it is:
1) dev_hdd0/COVERS as default (and remove the "covers" and "3D covers" directories from inside managunz installation path)
2) the covers downloaded online are stored in dev_hdd0/COVERS too
3) standarize the TITLE_ID's in format BLES12345.PNG, SLES12345.PNG, etc (without characters in between)
4) for the 3D covers add a suffix or prefix to the name, in format: BLES12345_3D.PNG, SLES12345_3D.PNG, etc
5) add an option inside managunz settings for "select covers path" (with the value dev_hdd0/COVERS as default) to allow the user to customize the name of the folder incase they doesnt likes dev_hdd0/COVERS
6) add another option to select the "file extension priority" (with options: JPG, jpg, PNG, png)



The suggestion 6 is because i realized in the actual source code the JPG extension (in uppercase) have priority over the others, and that extensions are scanned using a cascade of "if" statements
Personally i have the covers in PNG format, so i guess the cover scanning is less efficient for me (it takes more time because i need to "jump" several "if" statements until it finds the PNG extension). So... not sure, but i think this could improve the cover scanning times
The actual cover loading times are very good though, so this is a minor detail but i think it could help to improve the speeds a bit more
 
Last edited:
I compile managunz need webp
but build libwebp-0.3.1 get libwebp.a: could not read symbols: File format not recognized
I use 013-webp-0.3.1.sh scripts
how fix it?

Most of my 'external libs' (not included in psl1ght) are installed in my environement (configure, make, make install) that's why I didn't notice.
I didn't uploaded the libs source in previous update of managunz because my internet connexion was very very very slow and I didn't want to wait few hours to upload an update. But now my internet speed is high, so, i'll upload them all. I'll try to link every static lib tell me if it's working in your environment :p

@sandungas good idea ;)
 
This is one of the times when i suggest you a bunch of things and you reply with a short "i like it"... and then im not sure if i should be moderatelly happy (because you only liked a few of the suggestions), or very happy (because you liked all my suggestions)
But being moderatelly happy, or very happy... is happy anyway, so thanks for considering that suggestions, im going to like this feature a lot :)

Im going to review what i wrote, incase there is some doubt or im missing something
1) dev_hdd0/COVERS as default (and remove the "covers" and "3D covers" directories from inside managunz installation path)
2) the covers downloaded online are stored in dev_hdd0/COVERS too
This is the main reason why im suggesting this, i think is better to store the covers in a path external to managunz instalation directory, and that path should be given max priority, because it allows to remove the cover paths inside managunz installation directory

For the users that had a previous managunz installed, and have his covers under managunz installation path you could add a function that runs only at the first boot to move the covers to the new path (maybe with a text warning to advise the user about what is happening)
But as said, this function should be triggered only in the first boot, because is going to cause a delay in managunz boot time

3) standarize the TITLE_ID's in format BLES12345.PNG, SLES12345.PNG, etc (without characters in between)
The goal of this is to "noobify" the TITLE_ID's of PS1 and PS2 covers, because it looks a bit weird to have some covers usign different name formats, also because personally i always forget where are located the special characters of PS1 and PS2 TITLE_ID's, lol (and i guess there are many other users having the same problem)
So.. yeah 4 letters + 5 numbers is the most simple way, easy to remember, and will look fine when there are hundreds of images displayed in a list

4) for the 3D covers add a suffix or prefix to the name, in format: BLES12345_3D.PNG, SLES12345_3D.PNG, etc
This was just an idea, i think what i suggested using the suffix "_3D" matches fine, is easy to scan, and will look fine when displayed with the others in a list
My only doubt right now is if using the name "3D" is good enought (considering is intended to be an standard)
Maybe is better to use "FULL" instead of "3D"... i got this inspiration from the way how the covers are stored in some web databases, usually there is "FRONT", "BACK", "FULL", "DISC" (and sometimes a few more)
FRONT <--- this is what we use, is just the cover name doesnt includes it because is implicit
BACK <--- we dont need this, in all the playstation games FRONT and BACK are printed in a single sheet (except PS1)
FULL <--- for managunz "Flow 3D" interface
DISC <--- eventually someone could add support for them, personally i think is too much because is going to hit performance

5) add an option inside managunz settings for "select covers path" (with the value dev_hdd0/COVERS as default) to allow the user to customize the name of the folder incase they doesnt likes dev_hdd0/COVERS
This was not posible to do it before, but with this new suggestions is going to be relativelly easy (in the same way managunz allows to use custom names for the directories where the game backups are stored)
Another nice setting to customize things :)

6) add another option to select the "file extension priority" (with options: JPG, jpg, PNG, png)
And this is intended to improve speed, personally i use to have only a few games so i never felt any speed bottlenecks loading covers, specially since the changes you made to the memory management and the "preloading" of images, the speed is amazing, to be honest i thought it was imposible to achive that speed loading images, lol... but yeah... if you add this setting to select he priority of covers file extensions i guess is going to be a bit more faster. Not sure about it though, maybe the difference is going to be just a few miliseconds and is not going to be notable, but you know... a cummulation of small details gives as result something big :)
 
Last edited:
I noticed Chinese is translated by translator
here. translated by my self
http://www.mediafire.com/file/iev600fz5zm29sq/CN.txt/file
Nice :encouragement:
There are 2 language ID's for chinese, which one is your translation ? https://www.psdevwiki.com/ps3/Languages
10 = Chinese (Traditional)
11 = Chinese (Simplified)

I dont know anything about chinese, but i guess doesnt differs too much, incase you want to make both just upload them as 2 separated files


-----------------------
Btw @Zar im thinking you could prepare the code to allow to load the 20 system languages (from 0 up to 19) supported by the PS3 firmware
It could be handy to have the code ready even before the language files exists... because this allows managunz users interested in translating it able to load his file for testing it (before submitting the translation to you), this way they can review his translation multiple times while working in it to see how it looks
By now managunz supports 8 system languages, and 2 more not supported by the system (HU and SE ?)
https://github.com/Zarh/ManaGunZ/tree/master/pkgfiles/USRDIR/sys/loc

The biggest diffrence in between them is the languages supported by the system have an unique ID, and managunz can enable them automatically by reading the PS3 firmware system settings (and other features dependant of language that could be implemented eventually at some point, like loading language specific ICON0_XX.PNG, PIC0_XX.PNG, TITLE_XX from inside PARAM.SFO, etc...)

But.... i guess to achieve this would be needed to rename the language files to add the ID in them, this way:
00_Japanese.txt
01_English_US.txt
02_French.txt
03_Spanish.txt
10_Chinese_T.txt
11_Chinese_S.txt
99_Hungarian.txt
etc...

Im adding the prefix "99" to the languages not supported by the system firmware just to difference them... the point is this languages should be managed a bit different way than the others (needs to be enabled manually because managunz cant autodetect them at the first boot)
So basically.... if the file name starts with a "2 digit code" in between 00 and 19... it means is officially supported by the firmware (and the characters after the "2 digit code" doesnt matters)
And for all other languages... full freedon in the name, this allows to create languages that are variations, like "XX_Sandungero.txt" (for personal use or whatever lol, kind of thing that is not serious enought to be disrtibuted together with managunz)

The point is to prepare the code to load all that languages now (20 official + unlimited unnofficial)
Maybe this will encourage people to do more managunz translations
 
Last edited:
Nice :encouragement:
There are 2 language ID's for chinese, which one is your translation ? https://www.psdevwiki.com/ps3/Languages
10 = Chinese (Traditional)
11 = Chinese (Simplified)

I dont know anything about chinese, but i guess doesnt differs too much, incase you want to make both just upload them as 2 separated files


-----------------------
Btw @Zar im thinking you could prepare the code to allow to load the 20 system languages (from 0 up to 19) supported by the PS3 firmware
It could be handy to have the code ready even before the language files exists... because this allows managunz users interested in translating it able to load his file for testing it (before submitting the translation to you), this way they can review his translation multiple times while working in it to see how it looks
By now managunz supports 8 system languages, and 2 more not supported by the system (HU and SE ?)
https://github.com/Zarh/ManaGunZ/tree/master/pkgfiles/USRDIR/sys/loc

The biggest diffrence in between them is the languages supported by the system have an unique ID, and managunz can enable them automatically by reading the PS3 firmware system settings (and other features dependant of language that could be implemented eventually at some point, like loading language specific ICON0_XX.PNG, PIC0_XX.PNG, TITLE_XX from inside PARAM.SFO, etc...)

But.... i guess to achieve this would be needed to rename the language files to add the ID in them, this way:
00_Japanese.txt
01_English_US.txt
02_French.txt
03_Spanish.txt
10_Chinese_T.txt
11_Chinese_S.txt
99_Hungarian.txt
etc...

Im adding the prefix "99" to the languages not supported by the system firmware just to difference them... the point is this languages should be managed a bit different way than the others (needs to be enabled manually because managunz cant autodetect them at the first boot)
So basically.... if the file name starts with a "2 digit code" in between 00 and 19... it means is officially supported by the firmware (and the characters after the "2 digit code" doesnt matters)
And for all other languages... full freedon in the name, this allows to create languages that are variations, like "XX_Sandungero.txt" (for personal use or whatever lol, kind of thing that is not serious enought to be disrtibuted together with managunz)

The point is to prepare the code to load all that languages now (20 official + unlimited unnofficial)
Maybe this will encourage people to do more managunz translations
hmm 11 Chinese S
 
I had a similar idea about the covers (titleid_disc.jpg, title_back.jpg, titleid_side.jpg etc ...) but I don't think i'll do for every UI, perhaps just for Flow3D.
 
@sandungas it's already using the ID, but the ID is inside the file "STR_LANGCODE" . It's in hexa, so it can support up to 255 langages.
Oki, i see, so the ID's for "non-supported system languages" are given "in order of apparence"... and by now the only translation of this type is hungarian and you gave it ID=20, next one will be 21 and so on
btw, typo detected in the ID for HU.txt, you gave it value 0x20 (thats 32 decimal), but it should be 0x14 (20 decimal)

Still, there are some details of this system that doesnt convinces me completly, the names are a bit confusing, just using myself as an example... i had doubts what language was HU and SE
I imagined HU was hungarian (because DEX357) but now i realized SE is swedish (official ID 13)

In the "2 letter codes" of this table i used SV for swedish (instead of SE), dont remember why but probably there is some place in the firmware where appears as SV, anyway it doesnt matters much, but the point is the "2 letter codes" are not accurate enought, and are not explicit either, i think is better to dont use the "2 letter codes"
https://www.psdevwiki.com/ps3/Languages

And i think it would be better to display the language names in managunz interface translated to english, so:
Español = Spanish
Magyar = Hungarian
Svenska = Swedish
And so on...

---------------------
So... im going to suggest another thing, maybe is excesive though
1) in the .txt files rename STR_LANGUAGE to STR_LANGUAGE_NATIVE
2) add another STR_LANGUAGE_ENGLISH with the names translated to english
3) when the language is loaded in managunz interface (active) display the STR_LANGUAGE_NATIVE of the active language... and all the others in the language selector (not actives) displays the STR_LANGUAGE_ENGLISH

This allows to display the language names in english as im suggesting... and also allows to keep the "native" language names that already exists (mostly because it sucks to remove features)

Additionally (incase the filenames inside "loc" folder are not critical) i would use the long names translated to english too... so Chinese_S.txt, Swedish.txt, Hungarian.txt, and so on
 
Last edited:
Hmmmm, i just had a nice/evil idea to encourage people to create more translations

You can create the other files to complete the 20 system languages only with 2 strings (or 3 if you decide to implement the idea of the STR_LANGUAGE_NATIVE & STR_LANGUAGE_ENGLISH), this way:
Code:
STR_LANGUAGE_ENGLISH 	{Korean}
STR_LANGUAGE_NATIVE 	{한국어}
STR_LANGCODE 		{\x09}

Then the (theoretical) korean managunz user is going to see "Korean" in the language selector, and is going to think "hmm, cool im going to enable korean language"
But when the language is enabled all texts are still displayed in english, except the STR_LANGUAGE_NATIVE (because the korean language file inside "loc" directory is almost empty, so managunz loads all other strings from the default english=0x01, or from the strings hardcoded in the binary)
And at that point it could happen 2 things:
1) the user doesnt cares
2) the user comes here reporting a bug, and we can ask him/her to create the translation (got you !)
e9d.jpg
 
Last edited:
The "non-supported language" start at 0x20 just in case sony release an update with more language ID. The name of files aren't used at all on the screen, it's just for us. I let the translator choose what he wants.
 
The "non-supported language" start at 0x20 just in case sony release an update with more language ID. The name of files aren't used at all on the screen, it's just for us. I let the translator choose what he wants.
Ahh ok, so the 0x20 was a prevention :)
Please read again my previous post with the idea of the "translation bait", i wrote it in a hurry and had many typos and sentences with grammar errors
 
I don't want to 'trap' ppl with 'fake' features. If someone really want to make a translation, he'll find a way to contact me, (on github or psx-place) just like the others did. Also, in almost every update I add new features, so new strings to translate, I don't want bother the translators. It's based on voluntarees only.
 
It's always been a pleasure for me to discover new Managunz updates, ever since the very first release.

Thanks for keeping this great project going @Zar
;-)
 
Back
Top