afaik, install all is a debug setting. I tried this on ferrox. I'm not sure if qa flagging (the button combo, which is needed on ferrox) would have any barring.
If you can do it, the bonus would be background download. Very cool feature.
Yeah I already edited a script to automatically rename the pkgs, currently it only works with one pkg at a time but it can definitely be improved to rename more than one. The way it works atm is you download the pkg as download.png, that is saved into the photo directory. Because the directory name is dynamic based on the date you downloaded the photo, the script automatically grabs the current date and renames the file to /dev_hdd0/packages/download.pkg.Yes, that is an option, and PKG Linker could handle the PC side of it in theory, rename the pkgs, serve them, and generate the xmls with the png links and exploits for renaming, its just custom exploits to rename the png to pkg that need to be created, I suppose if we had one we could auto generate more easily based on it , that is all that is needed to complete the method really. it could be done.
That is why .p3t might be better, the folder is always dev_hdd0/theme, so its simpler, and same result i think.Yeah I already edited a script to automatically rename the pkgs, currently it only works with one pkg at a time but it can definitely be improved to rename more than one. The way it works atm is you download the pkg as download.png, that is saved into the photo directory. Because the directory name is dynamic based on the date you downloaded the photo, the script automatically grabs the current date and renames the file to /dev_hdd0/packages/download.pkg.
Yes themes may be the better choice, I just wasn't sure if themes were allowed with the background download method. It isn't a huge problem to do it with png files either, the only issue would be if the pkg was downloaded one day and then renamed on another.That is why .p3t might be better, the folder is always dev_hdd0/theme, so its simpler, and same result i think.
Also, there could be an exploit generated for each pkg, so its a 2 step situation, download, then rename, 2 icons on XMB for each pkg basically.
I am not sure, either, can you test. logically it should work as themes are bigger than pngs, so if it works for pngs...but you never know.es themes may be the better choice, I just wasn't sure if themes were allowed with the background download method. It isn't a huge problem to do it with png files either, the only issue would be if the pkg was downloaded one day and then renamed on another.
About generating exploits, do you mean editing a base js file and replacing the file paths accordingly, then hosting that on the PKG Linker webserver so it can be accessed on the PS3? If so, we could do that.
We can do that aswell, for custom on the fly links, but ideally an app like pkg linker would auto generate all png links and renaming exploits based on a folder of packages, just like it does now, but with renaming and exploits built in too.I was thinking, since we need to use the silk browser to perform background downloads, maybe an XMB link to open the silk browser with a simple local javascript page containing a textbox for the download link would work. Then the user could fill the textbox with the DL link, hit a button and the download starts, just a thought.
afaik, install all is a debug setting. I tried this on ferrox. I'm not sure if qa flagging (the button combo, which is needed on ferrox) would have any barring.
From what place can we start ?! any ideas !Install package files under debug setting isn't the same as the one on game category. and this can't be done without qa flag.
Maybe possible to unlock the menu without qa flag though.
I am not sure, either, can you test. logically it should work as themes are bigger than pngs, so if it works for pngs...but you never know.
We can do that aswell, for custom on the fly links, but ideally an app like pkg linker would auto generate all png links and renaming exploits based on a folder of packages, just like it does now, but with renaming and exploits built in too.
The advantage to the bubble method is that its a 1 step process (i think) , just inject the bubble, or install it via served pkg which is even better. so its a better method probably if we can use bubbles, as adding pkg, could be easy as installing a 100kb pkg. and will probably allow icons, and proper pkg info etc in download management. So we should still consider the bubble method too.
open_path /dev_flash/vsh/module/nas_plugin.sprx
open_path /dev_flash/vsh/resource/nas_plugin.rco
open_path /dev_flash/vsh/resource/qgl/rhm.qrc
open_path /dev_flash/vsh/resource/game_plugin.rco
I wouldnt say huge mess, we could have them all using same ID maybe, so its just one blank space, and maybe there is a way to have icon in the blank space somehow. I know its not ideal, its just less "hacky" then renaming pngs, Do we have full download control whenb downloading pkgs as pngs? Like pause resume etc?f we do this with pkgs it will be a huge mess, we would have to use the ForcedInstallTo pkg parameter which creates an empty entry on the XMB, which requires a database rebuild to get rid of.
You mean when you use the install all package files option.@DeViL303
So it looks like it's accessing following plugins when using IPF under debug settings (retail vsh)
Code:open_path /dev_flash/vsh/module/nas_plugin.sprx open_path /dev_flash/vsh/resource/nas_plugin.rco open_path /dev_flash/vsh/resource/qgl/rhm.qrc open_path /dev_flash/vsh/resource/game_plugin.rco
for nas_plugin.sprx patches (for cfw) :You mean when you use the install all package files option.
Interesting. I will look as nas_plugin.rco to see if there is any page names i can swap to enable it. Can you look at the sprx for possible patches that could be done with HAN exploit?
this is a thread of Bubble pkg make i see last year in psxhax and now i remember it and navigate back to that page @esc0rtd3w can talk about ?
Link : https://www.psxhax.com/threads/ps3-ofw-bubble-maker-for-dtu-method-by-esc0rtd3w.2608/page-2
https://github.com/esc0rtd3w/ps3-ofw-bubble-maker/releases/tag/0.2
View attachment 16159
sprx patches can be done in RAM with exploits like han enabler as far as i know, that is how it enables debug pkgs for example.for nas_plugin.sprx patches (for cfw) :
* Allow installation of pseudo-retail packages on CEX-DEX
* Allow installation of retail packages on CEX-DEX
* Allow installation of Debug packages
* Disable ECDSA Check
and none of those would work cause the sprx need to be resigned again so no sprx patches on OFW possible for now
I wouldnt say huge mess, we could have them all using same ID maybe, so its just one blank space, and maybe there is a way to have icon in the blank space somehow. I know its not ideal, its just less "hacky" then renaming pngs, Do we have full download control whenb downloading pkgs as pngs? Like pause resume etc?
Also, we could have pkg linker generate and host exploits to inject the bubbles, so you just have list of exploits instead of list of bubbles. possible you have to install 1 game data pkg first, that contains all the files to be injected
So when using Package Manger or old Install Packages Files one sprx,2 rco and qrc files will be called for the installtion to be executed ,right ? we can edit the rco or qrc but we can't apply patch to sprx cause it needs officiel signature and that we don't have it so why won't we make an tools that patch the nas_plugin.sprx externaly like Debug Package Enabler and HAN Enabler cause :@DeViL303
So it looks like it's accessing following plugins when using IPF under debug settings (retail vsh)
Code:open_path /dev_flash/vsh/module/nas_plugin.sprx open_path /dev_flash/vsh/resource/nas_plugin.rco open_path /dev_flash/vsh/resource/qgl/rhm.qrc open_path /dev_flash/vsh/resource/game_plugin.rco
View attachment 16161
correct me if im wrong. But we can patch sprx files in RAM cant we?
Yup thats what i am talking about we can't touch the sprx directly but we can get contact with him using external exploitsprx patches can be done in RAM with exploits like han enabler as far as i know, that is how it enables debug pkgs for example.
@Joonie correct me if im wrong. But we can patch sprx files in RAM cant we?