PS3 [ UPDATE v 1.45.10 ] webMAN MOD 1.45.08 - New Update provided by Aldostools

(UPDATE v1.45.10 -- Jan 13) Original Article (Jan 7) :
Following the recent official update to webMAN from @deank, we see the popular fork (webMAN MOD) from @aldostools now receive an update, When we seen developer deank develop this plugin from the ground up with the core features. We thought the plugin could not get much better back then, then developer aldostools took over alot of the development with the fork of webMAN MOD and have thought many times how can this plugin improve, but it does as the scene improves this must have plugin keeps up with the times
​

This update (v1..45.08) has numerous changes with improved CFW syscalls disabling, DeViL303's webMAN LaunchPad Add-on is now once again supported in the FULL version of the plugin, Some new VSH-Menu Backgrounds from Berion also his recent rebugfication theme come included as well. for those of you who like to stream your games from PC to PS3 note that ps3etsrv has also been updated (download below). The recent PKG handler, PkgLauncher & Mount Roms features are now found in all version types of webMAN MOD. View all the changes that developer Aldostools has applied to this update in the logs provided below

Update v1.45.10 - This update provides some improvements to a few features inside on wMM, CFW syscall disabling has seen improvements and changes to note, Also, there was some improvements to handle the webMAN LaunchPAD better, see full changes outlined below.

webMAN MOD Support / Info Thread can be viewed here.​

Latest Update

• 
  
  Update (1x) 1.45.10 Changelog (Jan 13, 2017)
  
  • Removed popup for BAD REQUEST / SERVER BUSY errors
  • Added option to fully disable CFW syscall 8 using R2+TRIANGLE
  • Syscalls show 'Partially disabled' if they were partially removed
  • Resized arrays for disable Syscalls (17 -> 16)
  • Reduced LaunchPad limit from 500 to 300 (This is to avoid system freeze due memory overload)
  • Adder more boundary checks generating XML of LaunchPad
  • LaunchPad XML is scanned only if wm_launchpad.xml exists
  • Moved position of 'Rename' in File Manager right-click menu
  
  
  1.45.08 Changelog (Jan 7, 2017)
  
  • PKG HANDLER, PKG LAUNCHER & MOUNT_ROMS now are standard features in all editions
  • Restored LaunchPad feature to FULL edition
  • Removed redirection of custom FW update returning to XMB (fixes the error 80028E01 accessing PSN; thanks to Joonie)
  • Added option to mount PS2ISO with ps2_netemu on B/C consoles using Cobra 7.5
    (use the tag [netemu] in the file name or add ?emu=ps2_netemu whem mounting a PS2ISO)
  • Added free space graphic for /dev_flash on File Manager
  • Mount /app_home or /dev_bdvd now perform unmount
  • Added disable CFW syscalls: 15, 202, 20
  • Fixed detection of firmware version for 4.81 DECR
  • Fixed exclusion of NTFS games with parenthesis ").ntfs["
  • Added PKG with rebugification theme by Berion
  • VSH Menu now installs 2 new background themes by Berion
  • Updated ps3netsrv build 20170106

Downloads:

• webMAN_MOD_1.45.08_Updater.pkg
• webMAN_MOD_1.45.08_Updater_rebugification_theme.pkg
  • prepNTFS_1.17.pkg
  • ps3netsrv_20170106.zip
  • UP0001-PKGLAUNCH_00-0000000000000000.pkg

Source: github.com/aldostools​

 

Ah.. oops. Looks like they added the direct NTFS support to webMAN MOD 1.45.11 though. I will check it out soon.

• Added direct NTFS support to 'Full Edition'
  Thanks to deank, freddy38510, bguerville, Zar, Joonie, Estwald.
• Added support for auto-mount game when an USB drive is connected
  • 'Check for AUTOBOOT.ISO on startup' must be checked
  • The USB drives to be checked are the ones selected in /setup.ps3 (except /dev_ntfs)
  • The game must be named AUTOMOUNT.ISO or a JB game copied to the root of the drive

Please feel free to test the 1.45.11 release and report any problems to us... Especially ntfs related problems...
However given the fact that various features are evolving very fast, be prepared for more changes & new wMM releases in the near future...

 

So... the change in height is not really needed... because are using the maximun height, but what height is that in pixels exactlly ?
Iirc... when you look at the default "album" icon images inside explrore_plugin.rco are 128x128... but that is not the real size displayed.. are scaled on real time to 160x160 iirc (not sure how to test this, i dont remember where i did see the 160x160 actually so maybe is not accurate)

I'm pretty sure that XMB doesn't display 128x128, and 160x160. Default icon size is 128x128 but... it's always scaled down when option is not choose and scaled up when option is choose. So in theory, the bigger resolution is the better. Unfortunately no because i.e 160x160 is scalled down twice... XMB is a visual horror for an artist. ;p

I discovered that when creating Rebugification as I used in this style grid effect on icons, and on grid every scaling is very visible as generating glitches.

And it's even worst, CellOS have broken PNG/DDS lib. Transparent is not correctly handling generating another glitches.

 

I'm pretty sure that XMB doesn't display 128x128, and 160x160. Default icon size is 128x128 but... it's always scaled down when option is not choose and scaled up when option is choose. So in theory, the bigger resolution is the better. Unfortunately no because i.e 160x160 is scalled down twice... XMB is a visual horror for an artist. ;p

I discovered that when creating Rebugification as I used in this style grid effect on icons, and on grid every scaling is very visible as generating glitches.

And it's even worst, CellOS have broken PNG/DDS lib. Transparent is not correctly handling generating another glitches.

Yes, is scaled down and up, i was not giving much details but i meant the "big" one when icon is selected

But is tricky to know the exact value is using, is something that needs to be inside the rco's, but is even more tricky than this because depends of the TV screen resolution used
For most/all of the images displayed on XMB... the rco's loads the sizes and position from the "xmb layout" files, there are 4 layouts
http://www.psdevwiki.com/ps3/XMB_Layouts

Imo 1080p should be prioritary for most mods... incase of doing a mod that only uses one of the layouts 1080p should be the the one most people is going to use
The others are important too... but the point is much easyer to only care about one of them because you can hardcode the positions and size values inside the rco files (and forget about the "xmb layout" files, doing it this way there is no need to modify them)

Returning to the thread... and the reason why im explaining this...
If you display an image on XMB in a good TV... with any resolution... if you get really close to the TV screen panel you can see the pixels (better with a magnifyer glass)
By counting them visually you can find the exact size XMB is using
This stupid trick should work with all resolutions... is the only way i know by now to find wich sizes are using to scale down/up this icons

P.S.
As said, this values should be in one (or several) rco files, incase of finding them... the next step should be to make the value conversion to look inside the "XMB layouts" the exact number
But still... this is going to tell the value for all 4 resolutions

By using the keys i suggested (<Pair key="icon_fixed_width"> and <Pair key="icon_fixed_height">) i guess the value is going to be applyed to all resolutions (maybe looks great in one resolution but looks like shit in others), not sure about this, but is the only problem i see in using it

 

afaik, the layout table creates a grid from which the tiers appear using x, y, sometimes z to modify size. I think z was misinterpreted as size since it's really the z axis.

@Berion , I have a tutorial, the icontex.qrc one, that explains how to modify transparency correctly. well, actually, it's translucency . on the xmb, sometimes white is transparent, but most often it's black. black can also be opaque if ur coloring certain things. your right though, it's a mess. even now, sony still has the sorting mechanic backwards (i.e. ascend in the xml is the opposite of what it shows in the rco). it's never been corrected even up to 4.81.

 

afaik, the layout table creates a grid from which the tiers appear using x, y, sometimes z to modify size. I think z was misinterpreted as size since it's really the z axis.

Yes, in rcomage there are a few details like the missing z axis that are a bit confusing
Just keep in mind.. everytime that appears values for x... then y.... the next one is z
It happens with position (x,y,z) and size (x,y,z)

For PSP there was only used 1 resolution (the resolution of the PSP screen) so that was all... all position (x,y,z) and size (x,y,z) was hardcoded inside rco's
But for PS3 there are 3 resolutions for TV and one more for PSP remoteplay... and there are lot of images that changes its position and sizes for every resolution mode... so the values for every position (x,y,z) and size (x,y,z) needs to be stored 4 times
In other words... if you want to know the exact "size X" of an icon... the firmware is not storing a single value for it... but 4

To solve this problem what sony did was to use the "xmb layout" files
Are not a "predefined grid", just works like a simple list of values (actually you can store values at any position in them), every value is given an "ID" based on the line of the .txt
The value in line 1 is given ID=1
Line 2 has ID=2
And so on

The PS3 rcos's only tells in wich line number the value is located
As example... in the runtime when something is loaded from inside an rco... lets say the rco needs to load the value on line 45... then based on the TV resolution used (lets say you have the TV in 1080p) the firmware loads the value from line 45 from layout_grid_table_1080.txt


P.S.
The values im talking about works as "overrides" of the simple "position" and "size" used on PSP
This is why in PS3 rco's the simple "position" and "size" are always = 0 (because PS3 doesnt uses them)
Is explained better in wiki, long explain

 

yeah, that's what glowball mistook for size when it was the z axis which is size technically. the lower the value, the larger the image iirc as the image gets closer to the screen. the numbers r generally absolute values since a negative integer usually causes a soft brick. this is based on my own research though, so I might be remembering wrong or wrong altogether.

 

Now you are mentioning it and for the record, there are other values that appears consecutivelly refered to x,y,z axis and could be a bit confusing
Works as scale multiplyers (so i named them in wiki: sizeScaleX , sizeScaleY, sizeScaleZ) Are in a range from -1 to 1 and admits decimals, and negative numbers, some examples:

1 is the original size
0.5 half the original size
0 invisible (i guess never tryed it, lol)
-0.5 half the size and mirrored
-1 original size and mirrored

As far i could see... this ones doesnt seems to be related with the "xmb layout" files though

 

dunno what u mean by mirrored, but I was referring to some of the values in the xmb wave. most r positive, but some r negative. changing one from the other results in a softbrick, possibly due to the value being read at the wrong offset.

 

dunno what u mean by mirrored, but I was referring to some of the values in the xmb wave. most r positive, but some r negative. changing one from the other results in a softbrick, possibly due to the value being read at the wrong offset.

Ok, the values used to create custom waves, i made long list of the values used in offical files http://www.psdevwiki.com/ps3/Lines.qrc#MNU_Settings

By looking at them (at every place where has been used) you can get an idea of the range, all are valid values because are official
Next to them appears the "data type" (most are floats in decimals) so initially is straightforward
What probably happens is some values could make the wave .elf to crash (some maths operations that could go crazy when using big values), the value is valid but the result is not

Btw, again for the record... by looking at that lists it can be seen there are other values that never has been used officially in the wave... but could be added to it

We need to think in them as "variables" used by the internal functions inside spline.elf
Is just we dont know the full list of variables allowed by it... we just know the ones sony used officially, but is highly probable that the spline.elf allows for more of them

 

yeah, it's been ages since I've made a wave. the last one was a vertical wave which is on here. I think we've kinda drifted off topic though. sorry, my fault.

 

Returning to the thread... and the reason why im explaining this... If you display an image on XMB in a good TV... with any resolution... if you get really close to the TV screen panel you can see the pixels (better with a magnifyer glass)
By counting them visually you can find the exact size XMB is using
This stupid trick should work with all resolutions... is the only way i know by now to find wich sizes are using to scale down/up this icons

There is better method. Just making icon plain square and making VSH screenshot when icon is enlarge and not enlarge. ;p

By using the keys i suggested (<Pair key="icon_fixed_width"> and <Pair key="icon_fixed_height">) i guess the value is going to be applyed to all resolutions (maybe looks great in one resolution but looks like shit in others), not sure about this, but is the only problem i see in using it

I'll try that in nearest occasion.

- - -

@pinky I understand how it works and believe me, Sony f*d this.