PS3 webMAN MOD - Web Commands

[OldGnashburg]

You must be talking about the slaunch menu, not sMan which is an alternative to webMAN-MOD altogether.
As with most things in wMM, you need to go to the webMAN-MOD setup page & configure the options in order to get the wMM behaviour you want.
Iirc you need to uncheck the "Game Menu" option (pad shortcut START / L2+R2) to get rid of the slaunch vsh menu.

Does that also unload it from memory?

 

[bguerville]

Does that also unload it from memory?

The code related to the feature is part of wMM so that's loaded in memory no matter what, wMM is not built around a modular design in which a disabled feature means no related module loaded & consequently no code related to the disabled feature in memory. But when a feature is disabled, most of the related code does not run so wMM won't use memory & cpu usage as much as if the feature was enabled.

If memory footprint caused by unused features is an issue for you then you have 2 options:

1. Use another of the available editions of wMM, one with fewer features.
To install a specific edition you must use a pad combo when launching the wMM installer self on XMB (the installer self you get on XMB after installing the wMM pkg).
The different wMM editions are detailed in the wMM general release thread OP & in the official github repo documentation.

2. If the available editions are not what you want, for instance if you need to pick & choose the available features yourself, you must recompile wMM after changing the small config file to enable/disable the features as you wish them. It's very easy to do & the compilation process is all automated but first you have to set up the compiling environment which is more time consuming (and strictly speaking probably illegal unless you have an official sdk license), for a one off compilation, I recommend you find someone to compile it for you, however for testing purposes, if you want to try certain combinations, you would have to setup the official sdk to build wMM, there is no alternative unfortunately as the open source psl1ght sdk doesn't support sprx file building, it must lack a fully functional prx linker or something like that.

It would be possible to make a new fork of the wMM project with the objective to make the project entirely modular with the features distributed in several secondary sprx library files to be loaded/unloaded dynamically on request.
Say for instance you want to open the slaunch menu, wMM would initialize data, load slaunch.sprx, use its functions & when the user closes the slaunch menu, serialise data to persist info if need be & then unload the slaunch sprx from memory. With the same overall behaviour for FTP, ps3netsrv etc...
It would also remove the need for the multi-edition installer & might help solve part of the memory footprint related issues by keeping the typical footprint when no module is used, when gaming for instance, as low as possible with only the wMM core plugin loaded in memory.

There might also be drawbacks to this approach, I cannot predict all the outcomes of such an implementation in wMM in practice, the consequences on performance, speed & the added overheads but I think it would be worth testing the concept with just one feature & take things from there.

I have written code to implement that modular approach in xai_plugin already, I will let you guys know how it fares when I get the opportunity to test it (I am flooded with more important work atm as I already have 2 public releases to work on with the new HEN installer & the PS3 Toolset update which will offer more new features than originally planned).

 

[aldostools]

The code related to the feature is part of wMM so that's loaded in memory no matter what, wMM is not built around a modular design in which a disabled feature means no related module loaded & consequently no code related to the disabled feature in memory. But when a feature is disabled, most of the related code does not run so wMM won't use memory & cpu usage as much as if the feature was enabled.

Unlike sMAN that have sLaunch built-in in the code of the plugin. sLaunchMOD (aka "Game Menu") is a standalone plugin that is loaded and unloaded dynamically from memory when the user presses L2+R2 or pressing START button for 3-5 seconds.

Same applies to VSH Menu, except that it is called pressing SELECT button for 3-5 seconds.

That means that these modules don't consume any memory when they are not in use.

Other services like PS3MAPI server, FTP server, the local PS3NETSRV, rawseciso and netiso plugins are built-in in the source code. That means that the memory footprint of these modules are loaded, but their processes (threads) are not loaded to memory if their options are unchecked or not in use.

The services rawseciso and netiso (used to mount NTFS/exFAT and NET isos) can be external-only adding #undef USE_INTERNAL_NTFS_PLUGIN and #undef USE_INTERNAL_NET_PLUGIN in main.c. However, I decided to keep them embedded in the code to reduce potential errors due external dependencies. Also the code for these plugins is small, so there isn't much benefit removing them.

The lite edition is recommended when the memory usage is critical.

 

[bguerville]

Unlike sMAN that have sLaunch built-in in the code of the plugin. sLaunchMOD (aka "Game Menu") is a standalone plugin that is loaded and unloaded dynamically from memory when the user press R2+R2 or pressing START button for 3-5 seconds.

Same applies to VSH Menu, except that it is called pressing SELECT button for 3-5 seconds.

That means that these modules don't consume any memory when they are not in use.

Other services like PS3MAPI server, FTP server, the local PS3NETSRV, rawseciso and netiso plugins are built-in in the source code. That means that the memory footprint of these modules are loaded, but their processes (thread) are not loaded to memory if their options are unchecked or not in use.

The services rawseciso and netiso (used to mount NTFS/exFAT and NET isos) can be external-only adding #undef USE_INTERNAL_NTFS_PLUGIN and #undef USE_INTERNAL_NET_PLUGIN in main.c. However, I decided to keep them embedded in the code to reduce potential errors due external dependencies. Also the code for these plugins is small, so there isn't much benefit removing them.

The lite edition is recommended when the memory usage is critical.

Good to know.
Thanks for the quick clarification Aldo.
;-)
It means the modular design functions well with custom vsh plugins, I wasn't aware you had already used it for the vsh menus in wMM.
It also means that my new xai_plugin implementation will work one way or another.

 

[aldostools]

Good to know.
Thanks for the quick clarification Aldo.
;-)
It means the modular design functions well with custom vsh plugins, I wasn't aware you had already used it for the vsh menus in wMM.
It also means that my new xai_plugin implementation will work one way or another.

If you want to see the code in action, check the function start_vsh_gui()
https://github.com/aldostools/webMAN-MOD/blob/master/include/ps3mapi.h#L114-L122

Spoiler

#define unload_vsh_plugin(a) ps3mapi_get_vsh_plugin_slot_by_name(a, true)
#define get_free_slot(a) ps3mapi_get_vsh_plugin_slot_by_name(PS3MAPI_FIND_FREE_SLOT, false)

static void start_vsh_gui(bool vsh_menu)
{
  unsigned int slot;
  slot = unload_vsh_plugin(vsh_menu ? "VSH_MENU" : "sLaunch");
  if(slot < 7) return; unload_vsh_gui();

  slot = get_free_slot(); char arg[2] = {1, 0};
  if(slot < 7) cobra_load_vsh_plugin(slot, vsh_menu ? WM_RES_PATH "/wm_vsh_menu.sprx" : WM_RES_PATH "/slaunch.sprx", (u8*)arg, 1);
}

 

[bguerville]

If you want to see the code in action, check the function start_vsh_gui()
https://github.com/aldostools/webMAN-MOD/blob/master/include/ps3mapi.h#L114-L122

Spoiler

#define unload_vsh_plugin(a) ps3mapi_get_vsh_plugin_slot_by_name(a, true)
#define get_free_slot(a) ps3mapi_get_vsh_plugin_slot_by_name(PS3MAPI_FIND_FREE_SLOT, false)

static void start_vsh_gui(bool vsh_menu)
{
  unsigned int slot;
  slot = unload_vsh_plugin(vsh_menu ? "VSH_MENU" : "sLaunch");
  if(slot < 7) return; unload_vsh_gui();

  slot = get_free_slot(); char arg[2] = {1, 0};
  if(slot < 7) cobra_load_vsh_plugin(slot, vsh_menu ? WM_RES_PATH "/wm_vsh_menu.sprx" : WM_RES_PATH "/slaunch.sprx", (u8*)arg, 1);
}

I see, they are standalone vsh plugins requiring their own slot.

The last thing I coded (but left untested) in xai_plugin attempts to use sprx files the way a self project does, it turns xai_plugin into a string parser & dispatcher, if the string is a webman/sMan query, it redirects it to webman (so it replaces existing proxy setups), if it is a CFW Tools query it loads cfwtools.sprx (recompiled as a standard sprx with a header file & an export stub for xai_plugin to link against), xai_plugin calls the appropriate exported function in cfwtools.sprx then closes cfwtools.sprx when done. Same kind of thing if the string is (a) file(s) operation(s) query, xai_plugin loads a file_io.sprx, uses the exported functions to perform the operations described in the query & closes the sprx when done..
I believe I also made stub library files to export the xai_plugin parsing/dispatching code as well as the file_io functions & certain cfwtools.sprx functions in order to make them accessible to other projects which may want to use them rather than reinvent the wheel or to keep their own projects lighter by delegating some of the work to readily deployed sprx files or even repack the sprx into their homebrew pkg.

Like I said, I left that project untested & unfinished (I wrote that code on a long distance bus ride some months ago lol) so I dunno how it will fare but if it works as I hope it will, it might serve as a good base to deploy more of those generic & reusable modules.

 

[LuanTeles]

@aldostools something really crazy are happening here LOL

<Pair key="module_name"><String>idle_plugin</String></Pair>
<Pair key="module_action"><String>/write.ps3/dev_flash2/etc/xRegistry.sys&t=01&pos=0x10E0C;/copy.ps3/dev_hdd0/game/PS34KPROX/USRDIR/toolbox/patches/web_browser/debug/setting.xml&to=/dev_hdd0/home/$USERID$/webbrowser/setting.xml;/write.ps3/dev_hdd0/home/$USERID$/webbrowser/setting.xml&t=%3Csetting%3E%3Cenable_debugmenu%3E1%3C/enable_debugmenu%3E&line=2</String></Pair>

It is writing in /dev_hdd0/game/PS34KPROX/USRDIR/toolbox/patches/web_browser/debug/setting.xml

instead of

/dev_hdd0/home/$USERID$/webbrowser/setting.xml

I'm using copy.ps3 to copy a base setting.xml with all tags already in it, but set to 0 as the original xml only has 0/2 entries and if I just use write to add text in a line position, it it won't work using multiple options, because it self-organizes after starting the web browser, so I made a pre-populated setting.xml to just change the values in it, as the web browser won't reorganize it and the other commands will set the specified lines to 0 or 1.



See the notification is right, but the source file is being modificated

 

[aldostools]

@aldostools something really crazy are happening here LOL

<Pair key="module_name"><String>idle_plugin</String></Pair>
<Pair key="module_action"><String>/write.ps3/dev_flash2/etc/xRegistry.sys&t=01&pos=0x10E0C;/copy.ps3/dev_hdd0/game/PS34KPROX/USRDIR/toolbox/patches/web_browser/debug/setting.xml&to=/dev_hdd0/home/$USERID$/webbrowser/setting.xml;/write.ps3/dev_hdd0/home/$USERID$/webbrowser/setting.xml&t=%3Csetting%3E%3Cenable_debugmenu%3E1%3C/enable_debugmenu%3E&line=2</String></Pair>

It is writing in /dev_hdd0/game/PS34KPROX/USRDIR/toolbox/patches/web_browser/debug/setting.xml

instead of

/dev_hdd0/home/$USERID$/webbrowser/setting.xml

webMAN MOD by default link the files in HDD0 when you use /copy.ps3

To override this behavior you should use //dev_hdd0 in the source or the destination paths.

 

[LuanTeles]

webMAN MOD by default link the files in HDD0 when you use /copy.ps3

To override this behavior you should use //dev_hdd0 in the source or the destination paths.

I added // just in the destination path but no effect

Edit:

using // in te source and destination did the job =)

Thanks @aldostools working as it should now

 

[bguerville]

nvrm

FYI

boot_init.txt script is executed after the yellow led starts blinking fast but before the fan control gets set.
It only executes if the COPY_PS3 feature is enabled in the build (like in the full wMM edition).

autoexec.bat script is executed a bit later after starting the ftp server + the ps3netsrv server & the yellow led blinking is turned off. It executes in all wMM editions regardless of the included build features.

 

[LuanTeles]

@aldostools

why themes installed with the command /install.ps3, as my example:

/install.ps3/dev_flash/vsh/resource/theme/01.p3t

copies it with a random name to dev_hdd0/theme ?

Mine became "CD_315676848.p3t" instead of keeping the original file name.


Other thing is , i don't know if it is caused by this but it is just expeculation, sometimes wHen i turn my console on, my DS3 does not sync i always thought its a problem of my controllers, but my friends after installing my mod are having the same problem very often on CFW, I always noticed that it only happened on CFW, when I'm on HFW it doesn't happen.

So i was thinking , could it be the boot_init.txt? somehow preventing the synchronization of the ds3 controller as it is initiates in the same time as the controller tries to be paired.

This is no big problem as we can just hold the ps button to turn off the DS3 and pressing it again will sync normally

 

[bguerville]

@aldostools

why themes installed with the command /install.ps3, as my example:

/install.ps3/dev_flash/vsh/resource/theme/01.p3t

copies it with a random name to dev_hdd0/theme ?

Mine became "CD_315676848.p3t" instead of keeping the original file name.

Aldo will tell you exactly why but having no knowledge at all about this, if I had to guess, I would probably go for a simple explanation to begin with, maybe something like using random names so as to avoid deleting or overwriting existing theme files in that folder.. My guess might be totally wrong though lol, let's see what Aldo says. ;-)

 

[LuanTeles]

Aldo will tell you exactly why but having no knowledge at all about this, if I had to guess, I would probably go for a simple explanation to begin with, maybe something like using random names so as to avoid deleting or overwriting existing theme files in that folder.. My guess might be totally wrong though lol, let's see what Aldo says. ;-)

I don't think it is really random, it is somehow calculated based on the source file name, when you run the command again, the xmb will prompt that the file name is already installed and ask if the user wants to replace it

 

[bguerville]

I don't think it is really random, it is somehow calculated based on something, when you run the command again, the xmb will prompt that the file name is already installed and a prompt to replace it

According to the source code comments, those p3t files are temporary files, using random or derived names often makes sense for temp files ultimately meant to be deleted.
Here is a wMM snippet that deletes them:

if((set || (_id > 0)) && (webman_config->resource_id[6] != _id))

				{

					char msg[0x100];

					scan("/dev_hdd0/theme/", false, "CD_*.p3t", SCAN_DELETE, msg); // delete temporary themes

					wait_for_xmb();

					installPKG(param, msg);

					set = save = true, webman_config->resource_id[6] = _id; // last selected theme

				}

 

[LuanTeles]

According to the source code comments, those p3t files are temporary files, using random or derived names often makes sense for temp files ultimately meant to be deleted.
Here is a wMM snippet that deletes them:

if((set || (_id > 0)) && (webman_config->resource_id[6] != _id))

                {

                    char msg[0x100];

                    scan("/dev_hdd0/theme/", false, "CD_*.p3t", SCAN_DELETE, msg); // delete temporary themes

                    wait_for_xmb();

                    installPKG(param, msg);

                    set = save = true, webman_config->resource_id[6] = _id; // last selected theme

                }

When they are meant to be automatically deleted? i have my dev_hdd0/themes populated with a lot of temporary themes, because i modded @DeViL303 theme downloader to apply the theme automatically after the theme being downloaded. Its not a problem, but hard to know the files there as they don't have names

 

[bguerville]

When they are meant to be automatically deleted? i have my dev_hdd0/themes populated with a lot of temporary themes, because i modded @DeViL303 theme downloader to apply the theme automatically after the theme being downloaded. Its not a problem, but hard to know the files therere as they don't have names

I am not sure, that's a question for Aldo really.

At first glance from the source, I would imagine the temp files in the theme folder are automatically deleted when themes are set to random, everytime a new random theme is applied.

The deletion snippet above is executed by

map_vsh_resource(u8 res_id, u8 id, char *param, u8 set)

when res_id == 5 (I assume that means theme package type) & the last selected random theme in wMM config is different from the one wMM is now trying to apply (id is the wMM defined theme id & the theme name should be found in param).
Use debug Cobra, the output should indicate what exact files are accessed. If you want further info, you need to add printf calls in wMM code & recompile or debug with ProDG directly in DEX mode if you are able.

I dunno if there are other occurrences of temporary p3t file deletion elsewhere in wMM, I didn't see any when I looked but I could easily have missed something, it's a big project.

 

[aldostools]

@LuanTeles The temporary themes (CD_*.p3t) are deleted when the random themes are applied a moment after the plugin is loaded (e.g. when the system starts up).

The random theme only occurs if the folder /dev_hdd0/tmp/theme was created with *.p3t themes (1-254).

These temporary themes are deleted, because every time a theme is installed by the randomizer a CD_<random name>.p3t is created in /dev_hdd0/theme. After multiple starts, the theme folder would be filled with copies, wasting unnecessary disk space and causing issues to the theme installion when the temporary file exists.

 

[LuanTeles]

@LuanTeles The temporary themes (CD_*.p3t) are deleted when the random themes are applied a moment after the plugin is loaded (e.g. when the system starts up).

The random theme only occurs if the folder /dev_hdd0/tmp/theme was created with *.p3t themes (1-254).

These temporary themes are deleted, because every time a theme is installed by the randomizer a CD_<random name>.p3t is created in /dev_hdd0/theme. After multiple starts, the theme folder would be filled with copies, wasting unnecessary disk space and causing to the theme installion when the temporary file exists.

I got it, so it only deletes the CD files if theme randomizer is on, i was wondering because i use a boot_init.txt to install a theme in the first boot after my mod is installed, so i was trying to find it in dev_hdd0/themes to be deleted by the uninstaller and i found a lot of CD files and i got confused which one was it.

So the reason i have many CD files is because i use the following commands to install themes but they are only deleted if the theme randomizer are set to on.

/download.ps3?to=/dev_hdd0/downloads&url=https://raw.githubusercontent.com/LuanTeles/Themes/main/files/Symbol_Flow.p3t;/popup.ps3?The theme will be automatically applied, please wait...&snd=1;/wait.ps3?10;/install.ps3/dev_hdd0/downloads/theme/Symbol_Flow.p3t

/download.ps3?to=/dev_hdd0/downloads&url=https://raw.githubusercontent.com/LuanTeles/Themes/main/files/Super_Heroes.p3t;/popup.ps3?The theme will be automatically applied, please wait...&snd=1;/wait.ps3?10;/install.ps3/dev_hdd0/downloads/theme/Super_Heroes.p3t

I had almost 100 of them lol, but no problem.

 

[LuanTeles]

@aldostools

Other thing is , i don't know if it is caused by this but it is just expeculation, sometimes wHen i turn my console on, my DS3 does not sync i always thought its a problem of my controllers, but my friends after installing my mod are having the same problem very often on CFW, I always noticed that it only happened on CFW, when I'm on HFW it doesn't happen.

So i was thinking , could it be the boot_init.txt? somehow preventing the synchronization of the ds3 controller as it is initiates in the same time as the controller tries to be paired.

This is no big problem as we can just hold the ps button to turn off the DS3 and pressing it again will sync normally

Btw @aldostools any tips about it?

 

[bguerville]

Btw @aldostools any tips about it?

Is the sync problem happening on every single boot & just sometimes? Does it happen when boot_init.txt is missing or empty?

Without more specific details and/or a way to reproduce the controller sync issue so it can be investigated further, it is not easy to provide definitive explanations.

But maybe Aldo can help, I dunno what feedback he may have gotten about this already.

I have experienced controller sync issues on boot when using the Cobra debug build & after software reboot call, mostly when using Target Manager. I don't recall having noticed any sync problems with wMM but I mostly use sMan on dev consoles nowadays.

Controller sync issues in CFWs on boot could be related to many things in theory.
* wMM or any other Cobra vsh plugin.
* Cobra stage2, release and/or debug build.
* A patch in the firmware's files, vsh or sprx modules, hard coded or applied dynamically by Cobra.
* Hardware issues, malfunction or compatibility.

In case of wMM, if ever it turns out to be the cause, the problem may also be dependent on configuration & on the custom boot scripts you may use, just like you speculated it might.

Short of debugging the problem yourself, you could test & compare the following 4 use cases, it would help you pinpoint to the source of issue.

1. Use the CFW with Cobra disabled for instance, use Mamba temporarily if you need a payload to run wMM.

2. Use the CFW with Cobra but without wMM or other vsh plugins loaded by boot_plugins.txt

3. Use the CFW with everything on, Cobra & wMM but no custom boot scripts (boot_init.txt, autoexec.bat, onxmb.bat...)

4. Use the CFW with everything on, Cobra & wMM including your boot scripts.

You could try booting say a dozen times in each use case, take note of controller sync issues in each case & report your findings.