WebMAN LaunchPad (webMAN MOD Add-On -Unofficial)

PS3 LaunchPad (Unofficial addon for webMAN MOD) v0.17

Seems @atreyu187 is having the same issue with two // in his links. Looks like there is bug in the Launchpad.xml generation code. He is using 1.45.09. I have not been using Launchpad now for a while and when I did my wMM was a bit out of date, so I have not come across this issue.
 
Seems @atreyu187 is having the same issue with two // in his links. Looks like there is bug in the Launchpad.xml generation code. He is using 1.45.09. I have not been using Launchpad now for a while and when I did my wMM was a bit out of date, so I have not come across this issue.


Attempting to fix it now and will report back.
 
Attempting to fix it now and will report back.

I notice you have lots of spaces in your filenames. They might work or they might not, in the xml the spaces are breaking the links, but the PS3 might read it differently. really the spaces should be replaced with %20 in the links, or removed from the filenames and replaced with underscores.

You can use a site like this to encode your links with %20 and whatever other characters needs replacing if it is a problem.

https://meyerweb.com/eric/tools/dencoder/
 
Hmm...
WMM should actually replace the spaces & other problematic characters when building the links afaik, such url encoding is usually taken care of already.
 
Hmm...
WMM should actually replace the spaces & other problematic characters when building the links afaik, such url encoding is usually taken care of already.

Yes, its possible some new bug has been introduced (along with the // bug which is confirmed), or its possible it was never an issue. Just stood out because the links were broken in atreyus xml (not clickable). It is encoding the cover links fully with %, but not the game mount links.
 
@aldostools

OK I just installed 1.47.05 & generated a wm_launchpad.xml file. Here is is an extract:
Code:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<nsx anno="" lt-id="131" min-sys-ver="1" rev="1093" ver="1.0">
<spc anno="csxad=1&amp;adspace=9,10,11,12,13" id="33537" multi="o" rep="t">

<mtrl id="1080001302" until="2100-12-31T23:59:00.000Z">
<desc>Unmount</desc>
<url type="2">http://127.0.0.1/dev_hdd0/game/XMBMANPLS/USRDIR/IMAGES/eject.png</url>
<target type="u">http://127.0.0.1/mount_ps3/unmount</target>
<cntry agelmt="0">all</cntry>
<lang>all</lang></mtrl>

<mtrl id="1080001301" until="2100-12-31T23:59:00.000Z">
<desc>webMAN Setup</desc>
<url type="2">http://127.0.0.1/dev_hdd0/game/XMBMANPLS/USRDIR/IMAGES/setup.png</url>
<target type="u">http://127.0.0.1/setup.ps3</target>
<cntry agelmt="0">all</cntry>
<lang>all</lang></mtrl>

<mtrl id="1080001304" until="2100-12-31T23:59:00.000Z">
<desc>Refresh LaunchPad</desc>
<url type="2">http://127.0.0.1/dev_hdd0/game/XMBMANPLS/USRDIR/IMAGES/refresh.png</url>
<target type="u">http://127.0.0.1/index.ps3?launchpad</target>
<cntry agelmt="0">all</cntry>
<lang>all</lang></mtrl>

<mtrl id="1080000000" until="2100-12-31T23:59:00.000Z">
<desc>Tomb Raider</desc>
<url type="2">http://127.0.0.1/dev_hdd0/game/BLES80608/USRDIR/covers/BLES01780.JPG</url>
<target type="u">http://127.0.0.1//mount_ps3/dev_hdd0/GAMES/Tomb Raider</target>
<cntry agelmt="0">all</cntry>
<lang>all</lang></mtrl>
Obviously we can see the 2 reported problems.
1. Url encoding not applied on mount links
2. Double '/' character in the url, between 127.0.0.1 & mount_ps3.
The strange thing is that only the mount_ps3 urls for mounting are affected by the double forward slash, the unmount urls for instance are correct as you can see.
 
@aldostools

OK I just installed 1.47.05 & generated a wm_launchpad.xml file. Here is is an extract:
Code:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<nsx anno="" lt-id="131" min-sys-ver="1" rev="1093" ver="1.0">
<spc anno="csxad=1&amp;adspace=9,10,11,12,13" id="33537" multi="o" rep="t">

<mtrl id="1080001302" until="2100-12-31T23:59:00.000Z">
<desc>Unmount</desc>
<url type="2">http://127.0.0.1/dev_hdd0/game/XMBMANPLS/USRDIR/IMAGES/eject.png</url>
<target type="u">http://127.0.0.1/mount_ps3/unmount</target>
<cntry agelmt="0">all</cntry>
<lang>all</lang></mtrl>

<mtrl id="1080001301" until="2100-12-31T23:59:00.000Z">
<desc>webMAN Setup</desc>
<url type="2">http://127.0.0.1/dev_hdd0/game/XMBMANPLS/USRDIR/IMAGES/setup.png</url>
<target type="u">http://127.0.0.1/setup.ps3</target>
<cntry agelmt="0">all</cntry>
<lang>all</lang></mtrl>

<mtrl id="1080001304" until="2100-12-31T23:59:00.000Z">
<desc>Refresh LaunchPad</desc>
<url type="2">http://127.0.0.1/dev_hdd0/game/XMBMANPLS/USRDIR/IMAGES/refresh.png</url>
<target type="u">http://127.0.0.1/index.ps3?launchpad</target>
<cntry agelmt="0">all</cntry>
<lang>all</lang></mtrl>

<mtrl id="1080000000" until="2100-12-31T23:59:00.000Z">
<desc>Tomb Raider</desc>
<url type="2">http://127.0.0.1/dev_hdd0/game/BLES80608/USRDIR/covers/BLES01780.JPG</url>
<target type="u">http://127.0.0.1//mount_ps3/dev_hdd0/GAMES/Tomb Raider</target>
<cntry agelmt="0">all</cntry>
<lang>all</lang></mtrl>
Obviously we can see the 2 reported problems.
1. Url encoding not applied on mount links
2. Double '/' character in the url, between 127.0.0.1 & mount_ps3.
The strange thing is that only the mount_ps3 urls for mounting are affected by the double forward slash, the unmount urls for instance are correct as you can see.

Ok. Well the other items like unmount are static, part of the xml template I expect or something like that. Not sure about the other issues or what is causing them.
 
Ok. Well the other items like unmount are static, part of the xml template I expect or something like that. Not sure about the other issues or what is causing them.
No, the unmount link isn't static per se.
It uses the exact same string replacement mechanism with the same local_ip variable as the mount link:
Code:
sprintf(url, "http://%s/mount_ps3/unmount", local_ip);
The same thing goes for other urls in wm_launchpad.xml which is is why I don't yet understand how this happens in mount links.
 
oh, well that's weird then. I would have expected them to be static as they never change and are included in the original template xml that installs with this.
 
oh, well that's weird then. I would have expected them to be static as they never change and are included in the original template xml that installs with this.
That's the thing. There are no static urls, I checked all those sprintf statements yesterday & I have not found a single one that looks suspicious. The mount_ps3 links should all be well structured in theory..
Aldo seems to be MIA...
And here it seems that only debugging will help now...
 
Could it be that the %s is including the extra / in the variable? and it works in the other standard view because the / is missing from the static section in that bit of code if you know what I mean.

So maybe removing the static / will work, and allow the other / that coming in with the variable to take its place, a work around kind of.

Or maybe it is the exact same code that generates both links, XMB view and Launchpad? but that is impossible or we would not have this issue in only one view.

Edit..or would we, because webMAN mod doesn't use the browser now does it, so maybe the proxy is not using the same format, or the // doesnt matter?
 
Last edited:
Could it be that the %s is including the extra / in the variable? and it works in the other standard view because the / is missing from the static section in that bit of code if you know what I mean.

So maybe removing the static / will work, and allow the other / that coming in with the variable to take its place, a work around kind of.

Or maybe it is the exact same code that generates both links, XMB view and Launchpad? but that is impossible or we would not have this issue in only one view.
Nope.
The local_ip variable is basically a constant (although not declared as one & that should actually be modified).
It's declared in main.c (line 740 in v1.47.05):
Code:
static char local_ip[16] = "127.0.0.1";
There is no extra forward slash that can be added with this variable.
 
hmm.. is it definitely the same code (and variables used) that generates the link for both views? because I remember it used to scan for XMB, then scan again for Launchpad..But it has changed a lot since slaunch and proxies etc so I don't know anymore.
 
hmm.. is it definitely the same code (and variables used) that generates the link for both views? because I remember it used to scan for XMB, then scan again for Launchpad..But it has changed a lot since slaunch etc so I don't know anymore.
The code isn't the same for xmb games list & launchpad but in both cases the algorithms use exactly the same string replacement process with sprintf calls using the same local_ip variable.
Those algorithms are in games_xml.h (xmb) & game_html.h (launchpad). I have reviewed them already & even posted (posts #516 & #519) those sprintf calls yesterday...
 
Well, I know what you are saying, but It cant be exactly the same and produce a broken link in one case and not the other..I don't know.

Now that a proxy is used by most people for quicker loading I assume that those links don't require any http address, so I suppose a lot has changed recently.

For the standard XMB view, how does it know what type of link to create and module to use in the xml, i mean proxy or web browser, does it go by detecting the if the proxy file exists and changing its behaviour to suit, is it possible that its also creating the standard web browser links with //, but no one has noticed as they all using slaunch/proxy? I cant test right now.
 
Well, I know what you are saying, but It cant be exactly the same and produce a broken link in one case and not the other..I don't know.
Obviously it can & it does. [emoji6]
More seriously I could have missed something of course...

Check post #516, as you can see using the proxy changes little to the url building process except that if the proxy is found, the module_action still requires the same information but not the full url with the ip address however there is also a fallback in case there proxy cannot be used:
Code:
if(use_wm_proxy)
							read_e = sprintf(tempstr, "<Table key=\"%04i\">"
											 XML_PAIR("icon","%s")
											 XML_PAIR("title","%s") "%s"
											 XML_PAIR("module_action","/mount_ps3%s%s/%s"),
											 key, icon,
											 templn, XAI_LINK_PAIR, neth, param, enc_dir_name);
						else
#endif
							read_e = sprintf(tempstr, "<Table key=\"%04i\">"
											 XML_PAIR("icon","%s")
											 XML_PAIR("title","%s") "%s"
											 XML_PAIR("module_action","http://%s/mount_ps3%s%s/%s"),
											 key, icon,
											 templn, WEB_LINK_PAIR, local_ip, neth, param, enc_dir_name);
As you can see, it's the same process using the same variables...
Also isn't the issue only with launchpad?
I cannot check until tonight now...
In the meantime, I will check the code for a typo somewhere but I am not optimistic. I fear that only debugging will help at this stage...
 
Last edited:
Obviously it can & its does. 
Check post #516, as you can see using the proxy changes little to the url building process except that if the proxy is found, the module_action still requires the same information but not the full url with the ip address however there is also a fallback in case there proxy cannot be used:
Code:
if(use_wm_proxy)
                            read_e = sprintf(tempstr, "<Table key=\"%04i\">"
                                             XML_PAIR("icon","%s")
                                             XML_PAIR("title","%s") "%s"
                                             XML_PAIR("module_action","/mount_ps3%s%s/%s"),
                                             key, icon,
                                             templn, XAI_LINK_PAIR, neth, param, enc_dir_name);
                        else
#endif
                            read_e = sprintf(tempstr, "<Table key=\"%04i\">"
                                             XML_PAIR("icon","%s")
                                             XML_PAIR("title","%s") "%s"
                                             XML_PAIR("module_action","http://%s/mount_ps3%s%s/%s"),
                                             key, icon,
                                             templn, WEB_LINK_PAIR, local_ip, neth, param, enc_dir_name);
As you can see, it's the same process using the same variables...
Also isn't the issue only with launchpad?
I cannot check until tonight now...

Well I don't see how the "exactly the same" code can produce two different results, I think its more likely there is a difference that just hasn't been found yet...

I don't know if its only with Launchpad, it has only been reported with Launchpad, but how many people are still using the web browser to load games? Im not sure if it popular anymore. Like you say the ip address is not used by those people using a proxy.

Its a weird one.. looking at the code I cant see where its coming from..
 
Could the variable not just be replaced with static "127.0.0.1" , is there any situation where that would not work?
 
Not using the ip address directly in the url building code is standard practice for decent programming. If changes were to be made to the ip address, to add a specific port for instance or because exceptionally the loopback interface points to a different address, only one variable needs modified in the code, instead of having to search for all the occurrences through the whole project to change them.

Using sprintf should always give the right result here as long as the value of local_ip does not change (which is why it's recommended practice to define such values as constant, in this case 'const char' rather than 'char' to ensure that the value can never be modified (except in cases of corruption of course). With C/C++, there is also always the risk of memory corruption changing the value. I doubt it here but it is always in the realm of possibilities.

If you can recompile WMM however you can try & see if removing the local_ip replacement in sprintf makes a difference..

I cannot test anything until tonight so if someone wants to give it a shot, here is what you should do (for the launchpad only):
1. Open the file game_html.h in the include directory.
2. Change line 1300:
Code:
flen = sprintf(tempstr, "http://%s/mount_ps3%s%s/%s", local_ip, neth, param, enc_dir_name);
becomes
Code:
flen = sprintf(tempstr, "http://127.0.0.1/mount_ps3%s%s/%s", neth, param, enc_dir_name);
3. Change line 1405:
Code:
flen = sprintf(tempstr, "http://%s/mount_ps3%s/%s", local_ip, param, enc_dir_name);
becomes
Code:
flen = sprintf(tempstr, "http://127.0.0.1/mount_ps3%s/%s", param, enc_dir_name);
I think that is sufficient for the launchpad.
Recompile & run...

My guess is that the issue isn't there though but later during the url processing in the function
add_launchpad_entry(..) line 693.
Maybe the character replacement algorithm or whatever fails but modifies the string with an added forward slash...?
To see the evolution of the value of the url & xml strings during processing in add_launchpad_entry() without debugging, you could for example add a line of code to get a pop-up message with the value like this:
Code:
show_msg(url);
.
To see if the url is ok before it is added to the xml, the best is to check the value before further processing.
Insert the line of code above line 697 & recompile. When you run it, as soon as the launchpad file gets created, the pop-up will show you the url before xml is processed.
Eventually you could also insert
Code:
show_msg(tempste);
.
in line 741, just before the "return size;" instruction to get a second pop up with the xml fragments containing the url after processing...
Instead of displaying a pop-up we could write the info to a file or whatever...

Warning: test with only one or 2 games though otherwise you will have an avalanche of pop-ups.... Lol
 
Last edited:
@DeViL303 just to make sure I am using launchpad installer 0.17 which has Rebug 4.81.2 install but I see this is a newer version. Should I try this? And I noticed the links were broken when I was editing it and notepad++
 
Back
Top