• PS3HEN is now supporting 4.93 Firmware

    View Official Release Post for additional information HERE

PS3HEN [Support Thread] PS3HEN Bugs, Problems, and Other Issues

aldostools said:
I think now I understand what you mean by "slot". I think you're refering to the function map_first_slot().
I don't know about map_path_by_slot(). Maybe you modified map_first_slot() to make it generic using index instead of [0].

The function map_first_slot(). was introduced in PS3HEN, probably by Habib or Joonie. There is not a "slot" system at all for map_paths.
Backup managers (like multiMAN or IRISMAN) clear all mapped paths when they start and can break the XMB menus.
map_first_slot() was added to prevent the deletion of the first mapped path, which is for hfw_settings.xml.

I added a similar system to Mamba and Cobra 8.3, keeping the same syscall 35 parameters: if the target path starts with /./ the path is not deleted by the backup managers when syscall(35, NULL, NULL) is called.

So that map_first_slot() is just an internal function of PS3HEN, that does not exist in Cobra or Mamba.

The function get_map_path() is also a new function introduced in Cobra 8.1 or 8.2.
I haven't seen any application using it yet. If you have a working version without changes, that's very good.

In regards to the priority system, it's a good idea. I hope it doesn't require a new syscall or break compatibility with existing apps.
That's why I implemented the "shadow path" and "protected path" using // or /./ respectively as prefix of the target path, instead of using a new parameter.

For now the workaround for the priority is deleting the existing mappings, and creating the new mappings in order (subdirectories first, then the parent directory).

@esc0rtd3w I updated payload/scsi.h and payload/storage_ext.c to add support for .sbi files and improve the performance seeking the custom subchannels. I attached the full project with compiled binaries, but you can take only these 2 files.

In my tests with .sbi (that format doesn't include the crc-16 data) I found that the PSX games work fine without calculating that hash. It looks like it's calculated internally by the SCSI driver. So I commented the function calculate_subq_crc() and the vector q_crc_lut[256]. It should be tested on HEN in case it behaves different.
Click to expand...
Ok, thanks.

I think Cobra and HEN should really be just one project with separate Makefile targets.
We would avoid all this confusion between functions that are here and not there..

I left get_map_path queries by index as it was, it is still valid as it can loop through the new linked list as it did with the old array.
There will be no changes to the syscalls, no legacy breaking, however I have had to introduce 2 new flags for folder mapping and priority mapping.
map_path can now remap folders properly. Once a mapping is applied, map_path reenters a loop of the mappings list to see if another mapping can be applied etc... so in theory a path can go through remapping multiple times before finally the resulting path string from the hook gets processed by the open_path function.

The maximum amount of mappings has been removed, we will soon test how the system performs with numerous mappings, say 100 or 1000...

The open_path hook doesn't seem to process all system file queries, it looks like only certain folders/file types in /dev_flash are accessed via open_path, I dunno how the other ones are handled.
If I had to guess, I would probably bet on an xmb/xcb server running at kernel level taking care of its own IO access without using the open_path function, if so, without a new kernel hook (still to be determined), remappings of many dev_flash based paths will remain impossible through map_path.
 
Last edited:
aldostools said:
I think now I understand what you mean by "slot". I think you're refering to the function map_first_slot().
I don't know about map_path_by_slot(). Maybe you modified map_first_slot() to make it generic using index instead of [0].

The function map_first_slot(). was introduced in PS3HEN, probably by Habib or Joonie. There is not a "slot" system at all for map_paths.
Backup managers (like multiMAN or IRISMAN) clear all mapped paths when they start and can break the XMB menus.
map_first_slot() was added to prevent the deletion of the first mapped path, which is for hfw_settings.xml.

I added a similar system to Mamba and Cobra 8.3, keeping the same syscall 35 parameters: if the target path starts with /./ the path is not deleted by the backup managers when syscall(35, NULL, NULL) is called.

So that map_first_slot() is just an internal function of PS3HEN, that does not exist in Cobra or Mamba.

The function get_map_path() is also a new function introduced in Cobra 8.1 or 8.2.
I haven't seen any application using it yet. If you have a working version without changes, that's very good.

In regards to the priority system, it's a good idea. I hope it doesn't require a new syscall or break compatibility with existing apps.
That's why I implemented the "shadow path" and "protected path" using // or /./ respectively as prefix of the target path, instead of using a new parameter.

For now the workaround for the priority is deleting the existing mappings, and creating the new mappings in order (subdirectories first, then the parent directory).

@esc0rtd3w I updated payload/scsi.h and payload/storage_ext.c to add support for .sbi files and improve the performance seeking the custom subchannels. I attached the full project with compiled binaries, but you can take only these 2 files.

In my tests with .sbi (that format doesn't include the crc-16 data) I found that the PSX games work fine without calculating that hash. It looks like it's calculated internally by the SCSI driver. So I commented the function calculate_subq_crc() and the vector q_crc_lut[256]. It should be tested on HEN in case it behaves different.
Click to expand...

unloading HENplugin.sprx is not fixed with this version.


To resolve the unloading issue you must fix stop_prx_module in henplugin/main.c and change
unload_prx_module to stop_prx_module in the prx exit point (SYS_MODULE_STOP and SYS_MODULE_EXIT).

Code: 
static void stop_prx_module(void)
{
    sys_prx_id_t prx = prx_get_module_id_by_address(stop_prx_module);
    int *result=NULL;
   
    uint64_t meminfo[5];
    meminfo[0] = 0x28;
    meminfo[1] = 2;
    meminfo[3] = 0;

    {system_call_6(SC_STOP_PRX_MODULE, (uint64_t)prx, 0, (uint64_t)(uint32_t)meminfo, (uint64_t)(uint32_t)result, 0, NULL);}

}

Code: 
int henplugin_stop()
{
	sys_ppu_thread_t t_id;
	int ret = sys_ppu_thread_create(&t_id, henplugin_stop_thread, 0, 3000, 0x2000, SYS_PPU_THREAD_CREATE_JOINABLE, STOP_THREAD_NAME);

	uint64_t exit_code;
	if (ret == 0) sys_ppu_thread_join(t_id, &exit_code);

	sys_timer_usleep(7000);
	stop_prx_module();

	_sys_ppu_thread_exit(0);

	return SYS_PRX_STOP_OK;
}
 
TheRouLetteBoi said:
unloading HENplugin.sprx is not fixed with this version.


To resolve the unloading issue you must fix stop_prx_module in henplugin/main.c and change
unload_prx_module to stop_prx_module in the prx exit point (SYS_MODULE_STOP and SYS_MODULE_EXIT).

Code: 
static void stop_prx_module(void)
{
    sys_prx_id_t prx = prx_get_module_id_by_address(stop_prx_module);
    int *result=NULL;
   
    uint64_t meminfo[5];
    meminfo[0] = 0x28;
    meminfo[1] = 2;
    meminfo[3] = 0;

    {system_call_6(SC_STOP_PRX_MODULE, (uint64_t)prx, 0, (uint64_t)(uint32_t)meminfo, (uint64_t)(uint32_t)result, 0, NULL);}

}

Code: 
int henplugin_stop()
{
	sys_ppu_thread_t t_id;
	int ret = sys_ppu_thread_create(&t_id, henplugin_stop_thread, 0, 3000, 0x2000, SYS_PPU_THREAD_CREATE_JOINABLE, STOP_THREAD_NAME);

	uint64_t exit_code;
	if (ret == 0) sys_ppu_thread_join(t_id, &exit_code);

	sys_timer_usleep(7000);
	stop_prx_module();

	_sys_ppu_thread_exit(0);

	return SYS_PRX_STOP_OK;
}
Click to expand...
Thanks.
An old classic.
I wasn't aware of the problem with the plugin, I don't use HEN, I am just helping out, I am surprised Habib made that mistake, he knew about this, an oversight maybe. Has it always been like this?
I will take care of it though.

@aldostools
@LuanTeles

The map_path work is done.
We tested with 100 mappings, no problems, it looks quite robust, no visible slow downs or perf impact, tonight Jason and I will test with 1000 mappings and start comparing performance with timers. Expect a test version over the weekend if all goes well.
 
Last edited:
bguerville said:
Thanks.
An old classic.
I wasn't aware of the problem with the plugin, I don't use HEN, I am just helping out, I am surprised Habib made that mistake, he knew about this, an oversight maybe. Has it always been like this?
I will take care of it though.

@aldostools
@LuanTeles

The map_path work is done.
We tested with 100 mappings, no problems, it looks quite robust, no visible slow downs or perf impact, tonight Jason and I will test with 1000 mappings and start comparing performance with timers. Expect a test version over the weekend if all goes well.
Click to expand...
The 2 archives that I submitted few days ago includes some changes to address the issue in HENplugin. I haven't tested it, due I don't use HEN. I used the same code used by VSH menu to unload. So I expect that it works.
 
aldostools said:
The 2 archives that I submitted few days ago includes some changes to address the issue in HENplugin. I haven't tested it, due I don't use HEN. I used the same code used by VSH menu to unload. So I expect that it works.
Click to expand...
Just like me, lol. I don't mess with my REX setup anymore, I cannot be bothered anymore reinstalling and setting everything back for development every 2mn.. All the little things...
I will check the files out and Jason will test.

If tonight's tests are successful, I will send you the Cobra source so you can test too.
I assume you are using that failsafe cobra feature.
What Cobra repo are you using though?
Nat's latest for 4.89? Your own?
Just so I can send you Cobra files that are in sync with what you use.
A second pair of eyes is ALWAYS useful on freshly written code...
 
Last edited:
bguerville said:
Just like me, lol. I don't mess with my REX setup anymore, I cannot be bothered anymore reinstalling and setting everything back for development every 2mn.. All the little things...
I will check the files out and Jason will test.

If tonight's tests are successful, I will send you the Cobra source so you can test too.
I assume you are using that failsafe cobra feature.
What Cobra repo are you using though?
Nat's latest for 4.89? Your own?
Just so I can send you Cobra files that are in sync with what you use.
A second pair of eyes is ALWAYS useful on freshly written code...
Click to expand...

I'm on Evilnat 4.88.2. I use MAMBA 8.4 for development.
I normally switch between MAMBA 8.4 and Cobra 8.3 (Normal or Debug).
I'm skeptical about the failsafe cobra :D (even when it was a feature we developed together)

Any test that I do will be done on MAMBA :cool:
 
@esc0rtd3w I recently downloaded HFW 4.89 Update.pkg without even realizing on my already jailbroken HEN 4.88 3.11 console, now I cant enable hen and idk what to do to fix that... can you please help me?
 
aldostools said:
I'm on Evilnat 4.88.2. I use MAMBA 8.4 for development.
I normally switch between MAMBA 8.4 and Cobra 8.3 (Normal or Debug).
I'm skeptical about the failsafe cobra :D (even when it was a feature we developed together)

Any test that I do will be done on MAMBA :cool:
Click to expand...
We tested the new code with 1000 mappings last night.
It exceeded kernel memory availability which was somehow expected...
After 650 to 850 mappings (it varies), alloc returns NULL, no kernel memory left to allocate.
When we stuck to say 500 mappings max, no problems, the new algorithm seemed solid, no performance impact was noticeable in the tests, more extensive testing will need to be done when using that amount of mapping though, any feature requiring the allocation of a substantial amount of kernel memory could be in jeopardy, we haven't found such a situation yet but it doesn't mean that it cannot happen, far from it.
According to our tests, I would estimate the kernel memory availability for mapping allocation to be about 1.2 to 1.6Mb on average so I propose to put a cap on mapping memory usage to around say 512kb (we can lower that maximum memory threshold to 384kb or even 256kb if necessary).
512kb should allow devs to register about 400 to 450 mappings max, possibly more for mappings done at cobra/hen level without the copy flag... Keeping in mind that folder mappings can save devs the trouble of remapping numerous individual files.
What do you think?

Last questions Aldo, you know more about the history of this feature than I do.
What is the situation with unmapping?
If we are to be thorough, shouldn't we have an unmap syscall too? Trivial to add at this point really, I already implemented all the necessary code and functions for mapping removal.
What is the situation with syscall 36? sys_map_game was it? Is this still used?
I don't know whether to add unmap to syscall 8 or just use something like syscall 37 or whatever, not sure a new syscall number is ideal for legacy brews disabling/hiding syscalls... So in the end I added code for both syscall 8 and 37, but commented the one for 37 for the time being, pending your feedback.
The new syscall 8 subcode for unmap is 0x7962, it takes one char* argument for old_path. The subcode for the already existing get_map_path syscall 8 being 0x7967, it takes 3 arguments, the slot/index number and 2 pointers to return the old_path and new_path values.

Also I realized that flags are not supported by the map_path syscall, they are used internally only. I may need to add a 3rd parameter to the syscall so devs can specify flags for folder and/or priority mappings. I would prefer not to change the syscall arguments at all but it looks like I will have to, hopefully a 3rd argument won't impact legacy stuff too much, we tested calling the newly updated syscall with only 2 arguments instead of 3 and everything worked as expected.
However while it should be ok for file remappings, folder mappings now need a special flag to be processed correctly, I don't think I can guarantee full backwards compatibility for legacy folder mappings made without flags..
I mean a folder mapping made with a legacy syscall still works but the mapping does not get applied to its sub folders and descendants because it's processed in the same way as a file mapping ie 1 level only.

You may ask why the flag is necessary to process folder mappings correctly so that it applies to all its descendants, folders and files.
The map table processing on open_path does not check the accuracy of mappings, it does not "stat" paths to find out whether the mapping arguments are coherent for instance, if a mapping's old_path is a folder, new_path should also be a folder, that kinda thing.
The responsibility to ensure mappings are coherent and flag's appropriate lays entirely on devs using the map_path syscall.
Similarly, the code relies only on the mapping flags to know whether a mapping is a file mapping or a folder mapping, so as to avoid having to stat the paths, otherwise the perf impact would be problematic, especially as it would most likely require mutex locks too for safe IO access from multiple threads...
The 2 new flags are relevant for the map_path syscall, the older ones are only relevant to internal HEN usage.
They are
FLAG_FOLDER 4
FLAG_MAX_PRIORITY 8
The folder flag must be used to remap all descendants of a mapped folder including both folders and files.
The priority flag can be used to indicate that the mapping should be added to a priority list that gets processed before the rest of the mappings.

I also added better error code returns to the map_path and get_map_path syscalls. When the map_path syscall succeeds it returns 0 as always, but when it fails, it returns the standard error codes for lack of memory, wrong argument or flag, resource unavailable etc... instead of returning -1. In theory, that should be fine with legacy apps unless they compared the return value to -1, that is quite unlikely though, I would assume that devs will probably have compared it to 0, either with "< 0" or with "== 0".
I sent Jason a HEN test build candidate a couple of hours or so ago, he will test it first then post it here if doesn't have any problems with it. I will try to make some mamba files for you today.

Btw are you on Telegram Aldo?
If so, would you mind if we switched to that? It would be easier to follow up on things and exchange files.
 
Last edited:
bguerville said:
We tested the new code with 1000 mappings last night.
It exceeded kernel memory availability which was somehow expected...
After 650 to 850 mappings (it varies), alloc returns NULL, no kernel memory left to allocate.
When we stuck to say 500 mappings max, no problems, the new algorithm seemed solid, no performance impact was noticeable in the tests, more extensive testing will need to be done when using that amount of mapping though, any feature requiring the allocation of a substantial amount of kernel memory could be in jeopardy, we haven't found such a situation yet but it doesn't mean that it cannot happen, far from it.
According to our tests, I would estimate the kernel memory availability for mapping allocation to be about 1.2 to 1.6Mb on average so I propose to put a cap on mapping memory usage to around say 512kb (we can lower that maximum memory threshold to 384kb or even 256kb if necessary).
512kb should allow devs to register about 400 to 450 mappings max, possibly more for mappings done at cobra/hen level without the copy flag... Keeping in mind that folder mappings can save devs the trouble of remapping numerous individual files.
What do you think?
Click to expand...
In my opinion, +400 is an overkill. 16 mappings has been enough for years, specially because mainly folders are mapped. All the files and subfolders are redirected with only one mapping. In the last few years it has been used to map individual files too, that's why I increased the vector to 32 items. LuanTeles is using them a lot, but I haven't read any comments about needing more mappings.

bguerville said:
Last questions Aldo, you know more about the history of this feature than I do.
What is the situation with unmapping?
If we are to be thorough, shouldn't we have an unmap syscall too? Trivial to add at this point really, I already implemented all the necessary code and functions for mapping removal.
Click to expand...
The situation is that we need to "lock" some mappings to be permanent.

Currently, backup managers like multiMAN or IRISMAN remove all the mappings when they start.
They used to be the unique method to mount games and they needed to clear the memory to avoid issues. At some point there was a "war" between developers, because the patches applied by one backup manager caused conflicts in the other and vice versa.

The method that I found easier to "lock" the mappings without add additional parameters (only 2 are used by most homebrews) was checking if the destination path starts with "/./" don't allow to remove it.

Currently I'm not using the "lock". Instead, I re-apply the mappings when I detect that XMB is loaded (e.g. after exit from a game). The reason I do this is because the "/./' was added recently and old Cobra versions ignore the "lock".

bguerville said:
What is the situation with syscall 36? sys_map_game was it? Is this still used?
Click to expand...
Syscall 36 is not used on webMAN MOD. It uses SYSCALL8_OPCODE_MAP_PATHS through syscall 8.
Syscall 35 is used only as a backup if syscall 8 is disabled.

However, I think old homebrews like multiMAN and other may be using syscalls 35 or 36.

IRISMAN uses syscalls 8 for MAMBA and 36 & 38:
// Remapper
#define SYSCALL_36 36ULL
// Sk1e Payload
#define SYSCALL_SK1E 38ULL

bguerville said:
I don't know whether to add unmap to syscall 8 or just use something like syscall 37 or whatever, not sure a new syscall number is ideal for legacy brews disabling/hiding syscalls... So in the end I added code for both syscall 8 and 37, but commented the one for 37 for the time being, pending your feedback.
The new syscall 8 subcode for unmap is 0x7962, it takes one char* argument for old_path. The subcode for the already existing get_map_path syscall 8 being 0x7967, it takes 3 arguments, the slot/index number and 2 pointers to return the old_path and new_path values.
Click to expand...
I prefer the use syscall 8 opcodes, instead of new syscalls. All the subcodes are dragged when syscall 8 is disabled/enabled. Also I prefer to use odd numbers for opcodes to avoid issues with LV1 dump (syscall 8 is LV1 peek too). I guess syscall 8 was reused to be "stealth", but may cause conflicts with partial dumpers.

bguerville said:
Also I realized that flags are not supported by the map_path syscall, they are used internally only. I may need to add a 3rd parameter to the syscall so devs can specify flags for folder and/or priority mappings. I would prefer not to change the syscall arguments at all but it looks like I will have to, hopefully a 3rd argument won't impact legacy stuff too much, we tested calling the newly updated syscall with only 2 arguments instead of 3 and everything worked as expected.
However while it should be ok for file remappings, folder mappings now need a special flag to be processed correctly, I don't think I can guarantee full backwards compatibility for legacy folder mappings made without flags..
I mean a folder mapping made with a legacy syscall still works but the mapping does not get applied to its sub folders and descendants because it's processed in the same way as a file mapping ie 1 level only.

You may ask why the flag is necessary to process folder mappings correctly so that it applies to all its descendants, folders and files.
The map table processing on open_path does not check the accuracy of mappings, it does not "stat" paths to find out whether the mapping arguments are coherent for instance, if a mapping's old_path is a folder, new_path should also be a folder, that kinda thing.
The responsibility to ensure mappings are coherent and flag's appropriate lays entirely on devs using the map_path syscall.
Similarly, the code relies only on the mapping flags to know whether a mapping is a file mapping or a folder mapping, so as to avoid having to stat the paths, otherwise the perf impact would be problematic, especially as it would most likely require mutex locks too for safe IO access from multiple threads...
The 2 new flags are relevant for the map_path syscall, the older ones are only relevant to internal HEN usage.
They are
FLAG_FOLDER 4
FLAG_MAX_PRIORITY 8
The folder flag must be used to remap all descendants of a mapped folder including both folders and files.
The priority flag can be used to indicate that the mapping should be added to a priority list that gets processed before the rest of the mappings.
Click to expand...
A new parameter is an easy solution for new homebrews that will require this specific new version of the payload. However the issue comes when you want to support legacy applications or don't want to force the developers to check Cobra version to know which API to use: the one with 2 or 3 parameters.

That's why I opted to don't use additional parameters and add the features based on the syntax of the current parameters.

bguerville said:
I also added better error code returns to the map_path and get_map_path syscalls. When the map_path syscall succeeds it returns 0 as always, but when it fails, it returns the standard error codes for lack of memory, wrong argument or flag, resource unavailable etc... instead of returning -1. In theory, that should be fine with legacy apps unless they compared the return value to -1, that is quite unlikely though, I would assume that devs will probably have compared it to 0, either with "< 0" or with "== 0".
I sent Jason a HEN test build candidate a couple of hours or so ago, he will test it first then post it here if doesn't have any problems with it. I will try to make some mamba files for you today.
Click to expand...
Yes, it's better that functions return specific errors, but to assume that the devs used "< 0" would be too optimistic. I prefer the pessimistic approach. Instead I would provide the returned error through a new opcode/function. Anyway, any application that will use the error will have to implement new code.

bguerville said:
Btw are you on Telegram Aldo?
If so, would you mind if we switched to that? It would be easier to follow up on things and exchange files.
Click to expand...
No. I can PM you my Whatsapp if you want. I don't use chat, except for office.
 
Last edited:
aldostools said:
In my opinion, +400 is an overkill. 16 mappings has been enough for years, specially because mainly folders are mapped. All the files and subfolders are redirected with only one mapping. In the last few years it has been used to map individual files too, that's why I increased the vector to 32 items. LuanTeles is using them a lot, but I haven't read any comments about needing more mappings.


The situation is that we need to "lock" some mappings to be permanent.

Currently, backup managers like multiMAN or IRISMAN remove all the mappings when they start.
They used to be the unique method to mount games and they needed to clear the memory to avoid issues. At some point there was a "war" between developers, because the patches applied by one backup manager caused conflicts in the other and vice versa.

The method that I found easier to "lock" the mappings without add additional parameters (only 2 are used by most homebrews) was checking if the destination path starts with "/./" don't allow to remove it.

Currently I'm not using the "lock". Instead, I re-apply the mappings when I detect that XMB is loaded (e.g. after exit from a game). The reason I do this is because the "/./' was added recently and old Cobra versions ignore the "lock".


Syscall 36 is not used on webMAN MOD. It uses SYSCALL8_OPCODE_MAP_PATHS through syscall 8.
Syscall 35 is used only as a backup if syscall 8 is disabled.

However, I think old homebrews like multiMAN and other may be using syscalls 35 or 36.

IRISMAN uses syscalls 8 for MAMBA and 36 & 38:
// Remapper
#define SYSCALL_36 36ULL
// Sk1e Payload
#define SYSCALL_SK1E 38ULL


I prefer the use syscall 8 opcodes, instead of new syscalls. All the subcodes are dragged when syscall 8 is disabled/enabled. Also I prefer to use odd numbers for opcodes to avoid issues with LV1 dump (syscall 8 is LV1 peek too). I guess syscall 8 was reused to be "stealth", but may cause conflicts with partial dumpers.


A new parameter is an easy solution for new homebrews that will require this specific new version of the payload. However the issue comes when you want to support legacy applications or don't want to force the developers to check Cobra version to know which API to use: the one with 2 or 3 parameters.

That's why I opted to don't use additional parameters and add the features based on the syntax of the current parameters.


Yes, it's better that functions return specific errors, but to assume that the devs used "< 0" would be too optimistic. I prefer the pessimistic approach. Instead I would provide the returned error through a new opcode/function. Anyway, any application that will use the error will have to implement new code.


No. I can PM you my Whatsapp if you want. I don't use chat, except for office.
Click to expand...
1. I will stick to using syscall 8 for everything.
2. I suppose I could just leave the old stuff as is in this case, untouched and just add new map/unmap path syscall 8 subcodes to leverage the new implementation.
It's not ideal imho, the old code is buggy and incomplete and the payload will grow in size but the legacy stuff will be fully protected and devs will be able to use the new stuff with flags, the errors issue will no longer be an issue and I will add a "protect flag" for those mappings that should NEVER be deleted.
3. And I don't use WhatsApp lol.
Well, it looks like I will have to post the updated mamba 8.4 stage2 folder here then.
 
Not sure about this: i can see some QA enabled options on hen3.1.1 .
"Update via system storage" and " Delete update data on system storage".
Slim 2001.
 
PLAYER 1 said:
Not sure about this: i can see some QA enabled options on hen3.1.1 .
"Update via system storage" and " Delete update data on system storage".
Slim 2001.
Click to expand...
that is normal if you've ever enabled the debug settings using the button combo, and used DEX menu options to change update behavior ( i cant remember the exact menu item)
 
This changes xmb
Code: 
<Query class="type:x-xmb/folder-pixmap" key="reload" attr="reload" src="xcb://localhost/query?sort=+Game:Common.titleForSort&cond=Oe +Game:Game.titleId RELOADXMB"/>
Why not change it to this in the static void reload_xmb(void) function? Then not only the hen icon will be replaced, but also the description for it
 
in1975 said:
This changes xmb
Code: 
<Query class="type:x-xmb/folder-pixmap" key="reload" attr="reload" src="xcb://localhost/query?sort=+Game:Common.titleForSort&cond=Oe +Game:Game.titleId RELOADXMB"/>
Why not change it to this in the static void reload_xmb(void) function? Then not only the hen icon will be replaced, but also the description for it
Click to expand...
That only works if the application is installed at dev_hdd0/game/RELOADXMB.
 
DeViL303 said:
That only works if the application is installed at dev_hdd0/game/RELOADXMB.
Click to expand...

And what is the difficulty in additionally installing it? We still pack with a custom packer.

By the way, I made a libaudio patch so that users can enable or disable it through the option. In my opinion this is optimal.

Code: 
PS3HEN/payload/modulespatch.c

CellFsStat stat;  
       
        for (int i = 0; i < N_PATCH_TABLE_ENTRIES; i++)
        {
            if (patch_table[i].hash == hash)
            {      
                #ifdef    DEBUG
                DPRINTF("Now patching  %s %lx\n", hash_to_name(hash), hash);
                #endif

                int j = 0;
               
                if((i==11) && (cellFsStat("/dev_hdd0/hen/hen_audio.off",&stat)==0))
                {
                    i++;
                    j++;
                }
               
                SprxPatch *patch = &patch_table[i].patch_table[j];

                while (patch->offset != 0)
                {
                    if (*patch->condition)
                    {
                        buf[patch->offset/4] = patch->data;
                        #ifdef    DEBUG
                            DPRINTF("Offset: 0x%08X | Data: 0x%08X\n", (uint32_t)patch->offset, (uint32_t)patch->data);
                            //DPRINTF("Offset: %lx\n", &buf[patch->offset/4]);
                        #endif
                    }

                    j++;
                    patch = &patch_table[i].patch_table[j];
                }

                break;
            }
        }
 
You must log in or register to reply here.

Similar threads

Back
Top