Pressing R1 + Circle while the in-game xmb is open appears to do nothing. Also, none of the in-game XMB icons are loading. Trying to close the in-game XMB will result in the timer icon in the top right spinning infinitely.
why not add function to cobra? I am using it on my own cobra and it works great
thanks, but damn. I had no problems when I was using my own game plugins...Pressing R1 + Circle while the in-game xmb is open appears to do nothing. Also, none of the in-game XMB icons are loading. Trying to close the in-game XMB will result in the timer icon in the top right spinning infinitely.
er wut? I have noticed you have added it to wmM, but not cobraIf you mean the function prx_start_modules it was already added in Cobra 8.3 (coming soon in Evilnat's 4.87.3)
https://github.com/aldostools/COBRA/blob/master/486/REX/stage2/modulespatch.c#L1071
MAMBA 8.3 also includes it:
https://github.com/aldostools/Mamba/blob/master/stage2/modulespatch.c#L1342
thanks, but damn. I had no problems when I was using my own game plugins...
can you send me this gta plugin? I will try myself
er wut? I have noticed you have added it to wmM, but not cobra
lol, does this work? I mean can you load system plugins with it? I wasn't so successful with it, if I remember right.
I have meant loading game plugins. you can copy vsh prx loading and make it game prx loading. you only have to get game process in hook function
and thanks, but this is not necessary with credits. I really don't need them and it can make me go bad
hey cool, how could I have missed this? thanks for your answerI haven't tampered much this function, but it seems to work with /gameplugin.ps3mapi (loading a system sprx in game process)
I think I found the cause of the issue.
Perhaps, i'm wrong... it need confirmation. An original EBOOT (and also the one you linked) have the lowest capability/control flag, he doesn't have access to everything, it's very limited, so, my guess is it doesn't have access to /dev_hdd0/tmp/ to launch the sprx. When you resigned the EBOOT I set the higher control/capability flag, so it does have access to these directory.
Why when you launch multiman you can access to this directory ? I can't be sure but my guess is deank added a fix_permission to every directory on /dev_hdd0, why ? because at 4.21 era if I remember correctly, these directory where all 'locked' with some CFW and caused lot of issue, most annoying was the infamous blackscreen ! ( I personnaly had this issue... and it took me lot of time to figure what was happening...)
So, to confirm my guess is to 'fix permission' on /dev_hdd0/tmp/ and try again![]()
if I remember right, this is exactly what I have told to someone on ngu, to use fixpermission on tmp in exactly the same context. I think this really has helped. now I am searching this thread on ngu, lol...I think I found the cause of the issue.
Perhaps, i'm wrong... it need confirmation. An original EBOOT (and also the one you linked) have the lowest capability/control flag, he doesn't have access to everything, it's very limited, so, my guess is it doesn't have access to /dev_hdd0/tmp/ to launch the sprx. When you resigned the EBOOT I set the higher control/capability flag, so it does have access to these directory.
Why when you launch multiman you can access to this directory ? I can't be sure but my guess is deank added a fix_permission to every directory on /dev_hdd0, why ? because at 4.21 era if I remember correctly, these directory where all 'locked' with some CFW and caused lot of issue, most annoying was the infamous blackscreen ! ( I personnaly had this issue... and it took me lot of time to figure what was happening...)
So, to confirm my guess is to 'fix permission' on /dev_hdd0/tmp/ and try again![]()
I think I found the cause of the issue.
Perhaps, i'm wrong... it need confirmation. An original EBOOT (and also the one you linked) have the lowest capability/control flag, he doesn't have access to everything, it's very limited, so, my guess is it doesn't have access to /dev_hdd0/tmp/ to launch the sprx. When you resigned the EBOOT I set the higher control/capability flag, so it does have access to these directory.
Why when you launch multiman you can access to this directory ? I can't be sure but my guess is deank added a fix_permission to every directory on /dev_hdd0, why ? because at 4.21 era if I remember correctly, these directory where all 'locked' with some CFW and caused lot of issue, most annoying was the infamous blackscreen ! ( I personnaly had this issue... and it took me lot of time to figure what was happening...)
So, to confirm my guess is to 'fix permission' on /dev_hdd0/tmp/ and try again![]()
really clever @Zar and again sorry for these offtopics from my side. if you wish you can remove my posts. I will make a new thread about this plugin loading anyways
how you found the eboot problem?
or just give a higher capability/control flag to the ebootSo if I understand correctly, correct me if I am wrong as I never use those sprx game mods, basically the problem comes from the mod itself. The eboot should check permissions & set them properly if found inadequate before launching the sprx. It does not look like a job that should be done by backup managers..