PS3 [Research] Modifying the Coldboot/Gameboot Sequence (custom_render_plugin.sprx/rco)

[LuanTeles]

Yeah we need to look into that more, it was actually the Ps3 pro mod qrc, luanteles found it online. When I looked in HEX, that one seemed to be corrupted like someone had used paste insert and moved a load of stuff down, breaking some MNU entries. This is still the only lines.qrc with the higgs particles afaik so there is something special about it.
.

I replicated the higgs in about 50 qrcs. ( i also made other types of particle effects)

To enable higgs just remove the values inside the desired environment (cooldboot 1 for the higgles on the coldboot, black/day/night/higure for the xmb depending on the time)

 

[DeViL303]

I replicated the higgs in about 50 qrcs. ( i also made other types of particle effects)

To enable higgs just remove the values inside the desired environment (cooldboot 1 for the higgles on the coldboot, black/day/night/higure for the xmb depending on the time)

OK, I see. So it is defaulting to some other settings if there are no MNU settings detected. Interesting.

So we could maybe try remove 1 line at a time and find out exactly which line is responsible, maybe.

That's if this defaulting to other settings works on a line by line basis.

 

[sandungas]

So we could maybe try remove 1 line at a time and find out exactly which line is responsible, maybe

Thats exactly what needs to be made, one by one
Also, after finding it... try to keep it but replace the value by 0, the result probably is going to be the same

The problem we was having in our experiments is we was dealing with entire MNU files (either deleting them or relinking them)... but there are MNU files that contains tenths of settings... so we had minimal control of what we was doing because we was changing tenths of settings with a single "patch", lol
Also, it was very hard to imagine which setting was generating the nice visual effect, when we started the hunting for the "higgs particle" i was always keeping an eye at the settings from the relinked files and i remember there was a point when i was sure i had only 3 posible candidate settings for it

Anyway... i dont remember which ones was that 3 settings... unless i wrote it somewhere in between our talks i guess we have missed that "hint"
Anyway... based on that... i bet the higgs particle is generated by a single setting... or a combination of 3 settings at most (but not more than 3 so there is no need to delete all the MNU settings like luanteles did)

 

[sandungas]

Yeap, exactly this one.

At the time, i didn't know well the rcos, i think i added it on the v1.x version

i was testing to see what are each image, so i changed several images with others already inside the rco, then i changed the bar and the notification to this one, i liked the result, also the xmb resized it automatically for the bar and notifications =)

But you scaled the image of the bubble down to 24x24 pixels ?, or you keept the original size of the bubble ?

Incase you used the original size of the bubble (bigger than 24x24) thats a proof of what i said in a previous post about improving his quality is going to work

-----------
Im going to make you some test images, im used to create tiny icons, i know very well how is made, and i would like to play a bit with that "glass tube" effect they used, there is a detail i dont like from it and i think i can "fix" it

 

[LuanTeles]

OK, I see. So it is defaulting to some other settings if there are no MNU settings detected. Interesting.

So we could maybe try remove 1 line at a time and find out exactly which line is responsible, maybe.

That's if this defaulting to other settings works on a line by line basis.

if i remember right, i tried to 0 all the settings and no higgs, only by erasing all the content i got them

 

[LuanTeles]

But you scaled the image of the bubble down to 24x24 pixels ?, or you keept the original size of the bubble ?

Incase you used the original size of the bubble (bigger than 24x24) thats a proof of what i said in a previous post about improving his quality is going to work

-----------
Im going to make you some test images, im used to create tiny icons, i know very well how is made, and i would like to play a bit with that "glass tube" effect they used, there is a detail i dont like from it and i think i can "fix" it

I keept the original size, i just ctrol+c crtol+v and renamed the image :P

 

[sandungas]

Luanteles, your screenshot is a proof that the streching is made following this pattern, thanks for clarifying it

After thinking a bit more in it, im not so sure how the streching works, when i said that is because i was focusing my attention at the corners, and in the screenshoots it can be seen the 4 corners are preserving the original pixels, because there is nice curve in them
But if we take the buble icon and divide it in 9 sectors following the rule i suggested, the result is this:

 

[sandungas]

I keept the original size, i just ctrol+c crtol+v and renamed the image :P

Do you remember if you cropped it the "empty" areas at top and bottom ?
You know... to reduce that distance in between the bubble and the top and bottom borders of the image

 

[sandungas]

I mean... if you cropped the image at top and bottom... and we apply the streching patterns i was suggesting, the result would be this

It fits a bit better with what can be seen in your screenshoots, but im not so sure if XMB is doing it this way

 

[sandungas]

Yes this is something regarding indication / indi_base etc. i always was curious about how it worked and tried to document how xmb_plugin is actually making it bigger or to display custom text in it. It would be more convenient instead the notification pop ups and messing with xil / xml files.
Yes there are basically some struct fields and just setting them 1/0 on runtime will actually make them appear...no need to modify xmb_plugin. I figured a bit that some parts of it are also happening in explore_plugin. I will have to search for my notes

Im confident is made by using animations... or better said... RCO TOC entry type 0x9

All this is a bit tricky to explain, but in resume... first thing that worths to be mentioned is the xml files generated by rcomage doesnt really exists inside the rco files, rcomage is using xml format just because is more "human readable" than the format used to store the info inside rco
The real format inside rco "splits" the data into tables, based in his data type, as can be seen in the rco header
And additionally there is a TOC where the info is stored in a special structure using ID's... this TOC is what rcomage uses to export/import to xml
I was burning my eyes with a hexeditor creating frankensteins RCO to understand how that TOC works, there are some examples in the RCO talk page in wiki, but specially this one that shows the complete TOC of official xai_plugin.rco from firmware 1.02

The goal of that TOC format is pretty much the same than what sony implemented later (at some middle point of PS3 lifetime) with the CXML format is just the RCO format is inherited from PSP so is a lot older than CXML but both are focused to the same purpose... what they are doing is to "condense" the info from a xml file into the smallest size posible and following very strict rules

Ok, returning back to what i was saying... the XMB is build using RCOXML Objects
Thats an unnnofficial name we use, just because rcomage "baptished" some of that formats, but i have to repeat it, is not xml inside the rco, are just ID's

As example, most of the icons and images displayed in XMB (unless we are talking about something special) are displayed by using a <plane> object

As you can see , the plane object starts with a group of attributes that includes an attribute named colorScaleA
Wel... the only thing you need to hide/show the icon is to attach that <plane> with a <recolour> animation (and change the value of alpha inside the animation)
Then is needed to use a code function to "trigger" that animation... usually are triggered by pressing butons or doing actions with the dualshock, but there are other special ones, and rare ones (an unique one is named "Ontick", only used by the clock, i think it counts processor ticks)

--------------------------
I really think (and im sure some of you agrees with me) there are some sprx that contains some kind of data intended to "override" what we see in the xml files generated by rcomage
In other words... the XMB displays many rcoxml objects that doesnt exists in the rco, that objects are overlapping what we see in the xml files generated by rcomage

In my oppinion, the only way to do this is by adding some areas in the sprx following formats pretty similar than the TOC of the RCO files (where the info is condensed, not human readable)
My guess is both are going to be identical... just because is a bit pointless to do conversions, and what they did in the rco TOC is not so bad (works good enought, and is tiny and efficient, so better dont change it)

Im metioning it just incase you find a way to identify where that areas are located in the sprx files... finding something like that could be a big step forward and could open doors to customizations

Btw, if i had to bet... i would say the area of the sprx where devil303 is deleting strings is the "strings table" of the kind of objects im talking about... is an expansion of the "strings table" of the rco "embedded" inside the sprx... and is directly related with another area of the sprx that should be an expansion of the rco TOC (but we dont know where is located)

 

[MeguminFanatic]

I not 100% sure. To me it looks like the corners are also squashed or something. The corner radius seems sharper?


@LuanTeles Are you saying its turning this:
View attachment 29284

into this:

Or do you have a custom square bubble added?

Yeap, exactly this one.

At the time, i didn't know well the rcos, i think i added it on the v1.x version

i was testing to see what are each image, so i changed several images with others already inside the rco, then i changed the bar and the notification to this one, i liked the result, also the xmb resized it automatically for the bar and notifications =)

I'm not really sure but actually i think it look's more like the trophy_tex_capsule located in explore_plugin_full.rco :

 

[DeViL303]

It does look more like that one if you consider the corner radius, but what I do not get is, why is the shine effect on the top left and not top right?

Is the PS3 mirroring it from left to right or what?

 

[MeguminFanatic]

To be honest, i don't really know. Maybe he mirrored the picture by editing the rco?

Edit:

I unpacked the ps3 4k pro xmb_plugin_normal and it seems that it has been edited manually

 

[sandungas]

View attachment 29308

I unpacked the ps3 4k pro xmb_plugin_normal and it seems that it has been edited manually

Thx, that fits a lot better with the streching patterns i was suggesting, can you upload the image tex_indi_bg.png inside a zip ?

 

[MeguminFanatic]

Here you go

 

[sandungas]

If you are curious, it looks like this when applyed the streching patterns

The original image is 24x24 pixels, and this one is 30x30 pixels, the reason why im cropping it this way is because im applying a simple math formula (that should work with other sizes). Just count the pixels of a border and divide it by 3
The original at 24x24 can be divided in 9 sectors of 8x8 pixels each
And this one in 9 sectors of 10x10 pixels each

 

[MeguminFanatic]

So i guess it work the same way for the notification and probably other objects?

planeResizeMode="0x3"

 

[sandungas]

So i guess it work the same way for the notification and probably other objects?

planeResizeMode="0x3"

Hmmm, i have lot of doubts how the attribute "planeResizeMode" works, read my notes at bottom of this section in wiki
As far i could see rcomage is reading it as a single value of 4 bytes lenght, but the value needs to be divided in 2 chunks of 2 bytes each
Thats a long story... the problem is rcomage is not splitting some of the values correctly, the easy way to fix that is by setting the value as data type "unk", im mentioninig it because you are entering in the unknown territory
Anyway, i really suggest you to use this version of rcomage where i made some minor changes like that, also the names of the attributes are synced with the info published in psdevwiki by me
As you can see the attribute appears with "int" data type, if at some point you find some rco using weird values in it remember... it could be because rcomage is doing incorrect data conversions, and you can change his data type (in the objattribdef-ps3.ini file) by "unk" to extract the value in raw hexadecimal code
By doing this we are disabling all the data types conversions made internally by rcomage (but still allows to rebuild the rco because the data is recovered from the xml in raw too)

What you said is a brilliant idea actually, if there is some attribute controlling this kind of streching effects it should be that one, looks like the better place to do it

 

[sandungas]

Yes this is something regarding indication / indi_base etc. i always was curious about how it worked and tried to document how xmb_plugin is actually making it bigger or to display custom text in it. It would be more convenient instead the notification pop ups and messing with xil / xml files.
Yes there are basically some struct fields and just setting them 1/0 on runtime will actually make them appear...no need to modify xmb_plugin. I figured a bit that some parts of it are also happening in explore_plugin. I will have to search for my notes

Returning to what you was searching for...
By looking at the results of devil303 test when he deleted the string "indi_base" from the sprx... i think indi_base is an "area" reserved at bottom of the frame to display text
I guess we agree up to this point

In my oppinion this is made by using the object named <Text> (in rcomage custom object names, that usually doesnt matches with the official codenames)... or better said the object with ID = 0x80D (this is an official ID)
The way how are stored that ID's in the RCO TOC is just by using 2 bytes... and are something "shared" in between the rco and the sprx file... this is why i said that i dont really think sony changed the ID's in between rco and sprx... doing it would be a nonsense... but well, im not going to bet my life on it because sony eventually does some things that are a bit weird... anyway, im just telling there is a huge probablity they used the same ID's in the sprx

The idea is... we know the ID's in the RCO TOC, so you could try to find them in the reversed IDA code, at some point of the functions that "generates" rco stuff on runtime
This is the table with all the ID's, is a value with 2 bytes lenght
https://www.psdevwiki.com/ps3/Template:RCO_TOC_entry_types

Basically... in the sprx you should have the value 0x080D (to create a <text>) and his parent should be a object with ID 0x0800 (to create the <ObjectTree>)

Also, the amount of pixels that icreases in the frame (to make room for the text) is directly related with an attribute used in text objects named "textFontSizeY"... this attributes doesnt have ID's though, but for a text is mandatory to indicate a lot of attributes, the ones that appears in this table
Are a lot of values, in the sprx should exist too, in the same order



Edit:
The text itself (the strings displayed by the <Text> object)... that is empty in devil303 test (because the sprx was not "injecting" them in the object structure)... is the attribute named "textMessage"... located inmediatly after the standard attributes
In the RCO TOC format the value stored by this attribute is a reference
The reference makes the loading to "jump" into <TextTree> to load a static text string

But i guess this reference to an static text should not exists in the sprx. What the sprx seems to be doing is to "inject" strings in the attribute "textMessage" of the object <Text> on runtime

 

[sandungas]

@LuanTeles i made an icon for your PRO MOD
What im doing here is to match the height mentioned by @DeViL303 here
He made a screenshot at 1080p of the bar and meassured the pixels in photoshop, and it seems to be 60x600 pixels (in his default size, not expanded)
That sizes doesnt looks like a coincidence, also they matches with the strenching formula i mentioned (the limits of the streching patterns are located at the side divided by 3)... in other words... the size of the image "should" have sizes that can be divided by 3

So... the icon i made have a size of 60x60 pixels. This way my icon is not going to be streched vertically when the bar have the default size (of 60 height)
This is how it looks when overlapped with the streching patterns:

DOWNLOAD ---> https://workupload.com/start/JC6knAr9HBC


Edit:
The glass effects i tryed to archive are a bit different though... is not a simple "glass tube"... if you dont like i could change them