They could apply this patch with hen, but no point as it wont be there at boot time which is when you need it.
The only thing HEN users can gain from this is by using the double // in xml mods if they are on flash, like this. I dont know of any that could use that currently to add some brick resistance, maybe my Homebrew folder mod if i was to release it for 4.85.
Original xml path on flash:
Brick resistant xml path on flash:
This is tested. Kind of interesting that it works in xml too but I guess that is to be expected. @sandungas
What im going to say is just speculation... but i think when you use the double // in a path the first / is taken as a indicator of a "subdirectory" and after it should be located the name of the directory, but the next character is another / and this is prohibited to use in directory names or file names... so at that point something weird happens (its magic)
Few small things I've discovered that may not be known and are kind of interesting
This first patch I call the Brick Resistant XMB Patch. Normally when the XMB loads initially, if any of the category xmls are missing, or the icontex.qrc file is missing then the PS3 kicks you to recovery.
I have discovered that this is just some kind of security check and not a real crash, and the PS3 is perfectly capable of booting regardless of missing files. This uses a little trick and some bad coding of the check in the first place I guess.
Myself and @Joonie and @sandungas discussed this before a little when we were talking about the definition of a crash. I was saying that I don't consider this a crash when you get kicked to recovery due to missing xml/qrc, I think a crash is when the PS3 loses control and freezes or similar. I think in the case of kicking to recovery due to missing FW files its not a crash but a sub routine,
Basically if issue = missing files on /dev_flash then = kick to recovery. The way I see it the PS3 is still fully in control and able to accept commands, its just decided to do something different based on its conditions it found itself in
The trick here is that the ps3 only kicks to recovery if its looking for xmls or qrc on /dev_flash/ specifically...So if we edit the path to be for example //dev_flash/ , well then the ps3 no longer cares about missing files and just continues to load what it can.
Another handy thing I discovered is that you can do this with a simple 1 byte patch to explore_plugin.sprx that makes all xmls brick resistant, so you dont need to edit each path and xml individually, just edit it here:
With that patch applied you can delete all xml for example, and you just get empty categories. You can apply the same patch to icontex.qrc in the custom_render_plugin.sprx, this patch might work in other places too.
IMO really this should be applied to all CFW as there is no downside.
You can even remap all category xmls to other paths like usb/hdd by just editing that one place as that is where %flash is defined. Any other paths than the default dev_flash will not kick to recovery if files are missing.
i applied the patch and deleted some xml to test it, and restarting the system is okay, but after shutting it down, it loads the xmb and kicks to recovery.
EDIT
I never could proper edit a sprx .
I right clicked on the sprx / self tools / extract efl
so i hexed the prx and them righ click/ self tools / resign Eboot/Elf
i applied the patch and deleted some xml to test it, and restarting the system is okay, but after shutting it down, it loads the xmb and kicks to recovery.
Maybe you have some custom xmls that use the full path path "dev_flash" and not "%flash"? Not sure. Shutting down and then restarting is the same thing as rebooting for these purposes, So something else must have changed. The place where you edited the path looks ok.
Maybe you have some custom xmls that use the full path path "dev_flash" and not "%flash"? Not sure. Shutting down and then restarting is the same thing as rebooting for these purposes, So something else must have changed. The place where you edited the path looks ok.
To make icontex.qrc brick resistant too. Due to there not being room in the sprx you need to shorten the name of icontex.qrc to icontx.qrc in the sprx, and don't forget to rename the file:
I was reapplying these patches on 4.89 and it seems this one is not needed, I was able to delete icontex.qrc without this patch.
Is there any specific situation where the deletion of icontex.qrc semi-bricks?
I patched it by including / in front of the path, I don't know if it will work as I can't semi brick my console, but I've used this method in other places that don't have enough rom and it worked just fine so I won't need to rename icontex to icontx
I think adding stuff before the path will still boot ok simply because it's ignored. The pointer that calls on that string/path starts reading from the 9th byte (08) on that row, afaik there is no mechanism that would allow it to read from the 8th byte (07).
Anyway it probably does not really matter too much, this mod is most useful on the xml paths, its not like people are modding/replacing icontex.qrc very often.
Just a heads-up: Using "xmb://localhost//dev_flash/vsh/resource/explore/xmb/" instead of "xmb://localhost/%flash/xmb/" seems to consume more system resources. When applied in registory.xml for use with items in the PSN category, it can cause issues when sorting trophies in groups, such as missing trophy icons or system freezes in the in-game XMB, due to the fact that sorting involves multiple filters. This is the only instance where I have found such problems. Additionally, although the in-game XMB becomes slower with the anti-brick patch, it is still worth the trade-off.
