ManaGunZ

PS3 ManaGunZ - PS3 Backup Manager by Zar v1.41

Go to download
Overview Extra info Updates (18) Reviews (5) History Discussion
kozarovv said:
Are you applying patch by yourself? I noticed that managunz is missing patches for PAL version of this game.

If you are applying patch by yourself, can you post patch file here. Also calculate CRC of your ISO and post it here.
Click to expand...
I'm using the pcsx2 patch. I note that the Iso's MD5 matches with redump's one when I check it in the PC, but when I check it with Managunz the MD5 is different
 
if you check the MD5 after applying any patch on the iso then the MD5 will be different because ManaGunZ apply the patches to the elf inside the ISO and pcsx2 is applying the patches to the elf loaded in the memory.

Anyway, I don't think the issue come from the iso.

It's probably come from ManaGunZ or the ps2emu of the ps3.
 
Instead of trying the game yourself and trying to replicate what the user did... im thinking you could do as other devs did in the past (i remember estwald did this before)

You can ask the user who is reporting the problem to "crop" the first 10mb of the iso or so (with a hexeditor or other tool) and send to you in a private message to examine it
This way you can see if there was some error when the patch was applyed

Is not the best method for debugging... but it can make things a bit easyer... and with luck this is going to be enought for you to see where is the problem
Is just an idea (and is not even me who imagined this)
 
@Zar I have question about config editor. Are you sure that every config from Command ID 0x01 need "param 1" ? For example functions like 0x1A to 0x2A looks like use fixed offsets. So I don't think there is any variable for them. I can be wrong here but 2x uint32_t Params ( offset, hack id 0-0x3B) is not correct for all 0x01 commands.
 
Yeah, probably but I didn't find any example with the command 0x1 with 0x1A < hack_id < 0x2A
The only example we have is hackID = 0x2 / 0x3 / 0x10 / 0xF (GTA and MaxPayne)

Also, I think when the ps2emu see the command 0x1, it expect to have always 2 uint32_t (the HackID is wrote after the offset) and if 0x1A < hack_id < 0x2A it will just ignore the value of the offset.
 
Hey @Zar, I got talking with Joonie about how some PSP games have to be launched as a PKG (and not using Cobra) or else their save read/write is broken. Apparently Cobra is set to use a different save location because that was the only way they could get it to work back in the day, but they don't want to change it back or else it would break everyone's previous PSP saves. We came to the conclusion that it might be possible to use the map_path function to remap the save data path, or somehow have MGZ make a symlink for each of the saves from the Cobra directory in the native save directory, so that all saves appear together and you don't have to choose between the locations.

As a side note, I was wondering, is it possible to add PSP "ISO.CONFIG" file support to MGZ, just like you did with PS2?

I hope you don't take these as "do this, do that", but just as suggestions/wonderings. I had originally thought of the saves thing because someone came to me saying that their game wouldn't save when launched via Cobra and placeholder, but would work when made into a PKG. Joonie said Patapon is a game that does this, if you are interested in try and needed one for testing.
 
But managunz uses the correct path for PSP saves ?
Personally i dont care about backward compatibility with previous PSP saves or placeholders
The way i see is the scene has to move on and sometimes are used methods that are fine for a time, but if eventually is find "the correct way" to do the things and the only option is to break backward compatibility with obsolete hacks... then is time to move on and break it

---------------
Someone from another forum mentioned me there is no "remote play" flag enabled in the PARAM.SFO of the last public managunz version, he enabled it by other means and works fine (normally, managunz main menu can be seen on psp, there is no problem of resources size, ram, or things like that)
Rebug enables the remote play modes automatically, right ? (cobra)... but i think you could enable it in the PARAM.SFO by default for the firmwares that doesnt makes that
 
sandungas said:
But managunz uses the correct path for PSP saves ?
Personally i dont care about backward compatibility with previous PSP saves or placeholders
The way i see is the scene has to move on and sometimes are used methods that are fine for a time, but if eventually is find "the correct way" to do the things and the only option is to break backward compatibility with obsolete hacks... then is time to move on and break it

---------------
Someone from another forum mentioned me there is no "remote play" flag enabled in the PARAM.SFO of the last public managunz version, he enabled it by other means and works fine (normally, managunz main menu can be seen on psp, there is no problem of resources size, ram, or things like that)
Rebug enables the remote play modes automatically, right ? (cobra)... but i think you could enable it in the PARAM.SFO by default for the firmwares that doesnt makes that
Click to expand...

I don't think @Derf Jagged delivered the word correctly, maybe some lost in translation.

Managunz has nothing to do with this psp save patch that is done by COBRA, it does what COBRA tells it to do so even with Managunz, the issue still occurs, @Derf Jagged was simply asking for help to fix this without updating/changing the COBRA payload.

the workaround for save data issue for certain games that were handled by COBRA way of doing PSP ISO with its placeholder aka PSP launcher was introduced 2 years ago by @haxxxen, he identified the which patch that caused the issue and added a new toggle feature to enable the patch on demand. The patch that was supposed to improve the compatibility had a bug for certain games like LOCO ROCO

@haxxxen and I figured that most games would just work without it, so his idea was to disable it by default but can be toggled on demand. I don't know if this can just be simply fixed by keeping the original COBRA patch at the same time the homebrew takes care of that save data issue by simple save data redirection by remapping the path of the save that the game was looking for.

Anyways, https://github.com/Joonie86/COBRA-7.3/commit/86e725e4afbddd572b91687223bdb77aeab07a93 <- I just updated the source and binary for anyone who's interested in this fix.
 
kozarovv said:
Why just don't use psp configs for fixing games? You can apply them to ISO with cobra PSP launcher.
Click to expand...

it also has nothing to do with the config, but the standalone psp minis/remastered pkgs aren't affected by this since the patch gets applied upon launching the PSP launcher only
 
Joonie said:
it also has nothing to do with the config, but the standalone psp minis/remastered pkgs aren't affected by this since the patch gets applied upon launching the PSP launcher only
Click to expand...
What exactly that patch is doing with savedata?

Asking because those are options available to reach without patching cobra:

  • SAVEDATA_USE_UPPERCASENAME =
  • FAKE_PATH = %s (max. lenght 0x400 bytes)
  • SAVEDATA_LOAD_CACHE_TARGET_NAME =
  • SAVEDATA_USE_PS3_SAVE = %lld SAVEDATA_USE_PS3_SAVE

0 = Uses PSP/PSPMinis SaveData module
1 = SaveGame via PS3 SaveData module
 
  • Like
Reactions: Zar
kozarovv said:
What exactly that patch is doing with savedata?

Asking because those are options available to reach without patching cobra:

  • SAVEDATA_USE_UPPERCASENAME =
  • FAKE_PATH = %s (max. lenght 0x400 bytes)
  • SAVEDATA_LOAD_CACHE_TARGET_NAME =
  • SAVEDATA_USE_PS3_SAVE = %lld SAVEDATA_USE_PS3_SAVE

0 = Uses PSP/PSPMinis SaveData module
1 = SaveGame via PS3 SaveData module
Click to expand...

it's probably forcefully setting it to use 1 [PS3 SaveData module] by patching pemucorelib.prx
 
Joonie said:
Because the patch ignores that part


Sent from my iPhone using Tapatalk
Click to expand...
That was my point when I asked why just don't use configs instead of patching cobra. Specially if it work that way.. Anyway current solution (CROSS + R1) seems good, but not perfect, there are more options that can be enabled permanently without losing compatibility like "bigger memory" (SDRAM_SIZE). This fix many games, and don't affect others. :)
 
kozarovv said:
That was my point when I asked why just don't use configs instead of patching cobra. Specially if it work that way.. Anyway current solution (CROSS + R1) seems good, but not perfect, there are more options that can be enabled permanently without losing compatibility like "bigger memory". This fix many games, and don't affect others. :)
Click to expand...

Can also alternatively be done by opcode and an extra config file to do the same toggle without using button combo. But when @aldostools and @habib tried something similar back then (ps1emu specific) it didn't work nicely if I remember it correctly


Sent from my iPhone using Tapatalk
 

  • About PSP SAVE : I think, the best solution is to use config files BUT there isn't any friendly interface to manage these options (YET). Also, for those who haven't the cobra7.53, the patch will be done 'forcefully" and I don't think it can be prevented. I'll remove this patch in mamba, when i'll write the PS1 CONFIG menu.

Right now i'm working on retroarch cores... so, the mgz update won't be rdy soon. (Also, the multilangage feature is a pita ^^').
 
You must log in or register to reply here.

Similar threads

Back
Top