PS3 [Research] RCOmage psdevwiki MOD v20180916

[sandungas]

Hmm, i think the textOverrideUnk57 is overriding the textLineSpacing or the textCharacterSpacing
99% of the texts in ofw are loading the value 0 as mentioned before, but there are a few that loads different values, like this one

textOverrideUnk57="0x9a030100" <---- this is loading the value 11 pixels (for 1080p resolution)

If you want to do a blindshoot test try the textOverrideUnk57="0x9a030100" in one of your custom texts to see if the characters are more separated

 

[sandungas]

Btw, for the record... i think in the next update im going to rename the numeral "suffix" of the unknown attribute names

It works like this...
Most of the objects (the objects are everything under <ObjectTree>) have a list of attributes that starts with a group of attributes that are common for all objects, in rcomage this group is named the "standard attributes", are 21, all them are known, they can be seen in this table
https://www.psdevwiki.com/ps3/Template:RCO_TOC_Objects_standard_attributes

Inmediatly after the 21 standard attributes are located the "specific attributes"... so technically the first specific attribute is located in position 22
Every object could have different specific attributes, some of them are unique for that object, and a lot of them are unknown

In the original rcomage this unknown specific attributes was given names like "unk26", "unk37", "unk52" etc... and when i renamed them for this mod i respected the "suffix" with the numbers, but most of the number suffixes are wrong, and right now doesnt makes sense
I prefer to use an strict rule to rename them based in his position than having random numbers :/

As example, take a look at the file objectattribdef-ps3.ini. This is the definition of a <Text> object:

[Text]
; -- BEGIN STANDARD ATTRIBUTE DEFINITION --
positionX = float
positionY = float
positionZ = float
colorScaleR = float
colorScaleG = float
colorScaleB = float
colorScaleA = float
sizeX = float
sizeY = float
sizeZ = float
sizeScaleX = float
sizeScaleY = float
sizeScaleZ = float
anchorMode = unk
onInit = event
positionOverrideX = unk
positionOverrideY = unk
positionOverrideZ = unk
sizeOverrideX = unk
sizeOverrideY = unk
sizeOverrideZ = unk
; -- BEGIN SPECIFIC ATTRIBUTE DEFINITION --
textMessage = text
textFontStyle = ref
textFontMode = unk
textUnk29 = unk
textFontSizeY = float
textTopColorScaleR = float
textTopColorScaleG = float
textTopColorScaleB = float
textBottomColorScaleR = float
textBottomColorScaleG = float
textBottomColorScaleB = float
textLineSpacing = float
textUnk37 = unk
textUnk38 = unk
textUnk39 = unk
textCharacterSpacing = float
textShadowOffsetX = float
textShadowOffsetY = float
textShadowOffsetZ = float
textShadowColorScaleR = float
textShadowColorScaleG = float
textShadowColorScaleB = float
textShadowColorScaleA = float
textUnk48 = unk
textUnk49 = unk
textUnk50 = unk
textUnkFloat51 = float
textUnkFloat52 = float
textUnkFloat53 = float
textUnkFloat54 = float
textResizeMode = int
textOverrideUnk56 = unk
textOverrideUnk57 = unk
textOverrideUnk58 = unk

"textUnk29" is located at position 25... so it should be renamed to "textUnk25"
"textUnk37" is located at position 34... so it should be renamed to "textUnk34"
And so on...

To do this is going to be needed to rename... dunno... 100 attributes or more
Is a big amount of names changed, but is about time to do it

Yes, i know this change doesnt matters much, but now that we are talking about the unknowns i have the feeling that is better to do it

 

[LuanTeles]

Hmm, i think the textOverrideUnk57 is overriding the textLineSpacing or the textCharacterSpacing
99% of the texts in ofw are loading the value 0 as mentioned before, but there are a few that loads different values, like this one

textOverrideUnk57="0x9a030100" <---- this is loading the value 11 pixels (for 1080p resolution)

If you want to do a blindshoot test try the textOverrideUnk57="0x9a030100" in one of your custom texts to see if the characters are more separated

Strange no difference, i tried some values in the textOverrideUnk57 and i got no effect

 

[sandungas]

I just found an small patch for rcomagegui.exe
You know, when you open it, by default it have the checkboxes for file format conversions enabled, this way:

Personally i use to disable them most of the times, so i was taking a look at the .exe in a hexeditor to see how is stored that default state info for the checkboxes, seems to be just a byte, im using a short search pattern because the values only appears 4 times in the file, and the 4 are the checkboxes that can be seen in that screen

Conversions off by default
SEARCH: 1301
REPLACE: 1300

*Only replace the first 3 apparences (not the fourth, the fourth is to "separate resources types into separated folders")


-------------------------
I have not tested this much, i just found it, consider it experimental, if you like it and works fine for you please report back

 

[LuanTeles]

Im taking a look at a radom rco (impose_plugin.rco) and it seems most of the <Text> objects uses this values:

textFontSizeY="10" textOverrideUnk56="0x14000000" textOverrideUnk57="0x3000000"

To me it looks the firmware is loading the textFontSizeY="10", otherway there is no reason for that value to be there... but i dont know is a bit confusing
Im posting here the value of textOverrideUnk57="0x3000000" just to show that is loading a 0... but doesnt seems to be related with the text heights... anyway is doing something

And the overrides are loading this values (from the file layout_grid_table1080.txt), 0x14000100 is line 21 in the .txt (and the other values next up to line 28)

0x3000000 = 0 pixels (for 1080p resolution)
0x14000100 = 23 pixels (for 1080p resolution)
0x15000010 = 21 pixels (for 1080p resolution)
0x16000100 = 19 pixels (for 1080p resolution)
0x17000100 = 18 pixels (for 1080p resolution)
0x18000100 = 187 pixels (for 1080p resolution)
0x19000100 = 113 pixels (for 1080p resolution)
0x20000100 = 60 pixels (for 1080p resolution)
0x21000100 = 187 pixels (for 1080p resolution)


Edit:
probably this ones are going to fit better with the sizes you want
0x12000100 = 32 pixels (for 1080p resolution)
0x13000010 = 26 pixels (for 1080p resolution)

Im taking a look at a radom rco (impose_plugin.rco) and it seems most of the <Text> objects uses this values:

textFontSizeY="10" textOverrideUnk56="0x14000000" textOverrideUnk57="0x3000000"

To me it looks the firmware is loading the textFontSizeY="10", otherway there is no reason for that value to be there... but i dont know is a bit confusing
Im posting here the value of textOverrideUnk57="0x3000000" just to show that is loading a 0... but doesnt seems to be related with the text heights... anyway is doing something

And the overrides are loading this values (from the file layout_grid_table1080.txt), 0x14000100 is line 21 in the .txt (and the other values next up to line 28)

0x3000000 = 0 pixels (for 1080p resolution)
0x14000100 = 23 pixels (for 1080p resolution)
0x15000010 = 21 pixels (for 1080p resolution)
0x16000100 = 19 pixels (for 1080p resolution)
0x17000100 = 18 pixels (for 1080p resolution)
0x18000100 = 187 pixels (for 1080p resolution)
0x19000100 = 113 pixels (for 1080p resolution)
0x20000100 = 60 pixels (for 1080p resolution)
0x21000100 = 187 pixels (for 1080p resolution)


Edit:
probably this ones are going to fit better with the sizes you want
0x12000100 = 32 pixels (for 1080p resolution)
0x13000010 = 26 pixels (for 1080p resolution)

I will take a look at this =) nice finding, i will check the layout tables.

0x12000100 does not work but 0x13000010 works good, but still small , i will check some other values.


EDIT : changing0x12000100 to 0x12000010 works

Why some are 0x??????100 Others 0x??????010 ?

i will need to check how the overrides works in your post again :P

 

[LuanTeles]

Nice finding

I will take a better look tomorrow, but by now i can tell you some hints

Usually the override attributes that are together belongs to coordinates and are X,Y,Z either for positions or sizes... but in this case could not be that way, textOverrideUnk56, textOverrideUnk57, and textOverrideUnk58 could not be related with each other

In lot of programs when dealing with text sizes (or font sizes) there is no need to tell the sizeX, sizeY, and sizeZ... you just need to tell the sizeY because sizeX is adjusted automatically (because the width of each character is specifyed in the font file) and sizeZ doesnt matters. Maybe this is one of that cases, you are changing sizeY but the other unknowns next to it could be something different

All the override attributes are specific for PS3 (the PSP doesnt even understands them). The purpose of them is to modify some of the other attributes in that same object that existed for PSP, most specifically the ones related with sizes or positions. So the actual attribute named textOverrideUnk56 could be modifying the other attribute named textFontSizeY. If this is true then the attribute named textOverrideUnk56 should be renamed to textOverrideFontSizeY

-------------------------
If you want to play around a bit with other unknown attributes related with text, try this ones (this is copyed from objectattribdef-ps3.ini)

textUnk48 = unk
textUnk49 = unk
textUnk50 = unk
textUnkFloat51 = float
textUnkFloat52 = float
textUnkFloat53 = float
textUnkFloat54 = float

I think are related with the "glow" effect. You know, like in PSP, actually there are used a lot in PS3 with the value 1 for colors (because the glow is always white), and 0 for positions (because the glow is perfectly aligned with the font)

I think they needs to be renamed like this (and the data type of the first 3 needs to be changed to "float")

textGlowOffsetX = float
textGlowOffsetY = float
textGlowOffsetZ = float
textGlowColorScaleR = float
textGlowColorScaleG = float
textGlowColorScaleB = float
textGlowColorScaleA = float

But you know... to test this you need to use an official text that have the glow already enabled... and it needs to be a text you know very well
This way you can change his color, and his position a bit to disalign it... then in XMB with the dualshock you select the text to see if the glow effect have changed

i will make some tests too

 

[LuanTeles]

I will take a look at this =) nice finding, i will check the layout tables.

0x12000100 does not work but 0x13000010 works good, but still small , i will check some other values.


EDIT : changing0x12000100 to 0x12000010 works

Why some are 0x??????100 Others 0x??????010 ?

i will need to check how the overrides works in your post again :P

I tested several values in the textFontSizeY="??" and it still does not affect anything

tested in the psp and it worked

 

[sandungas]

Strange no difference, i tried some values in the textOverrideUnk57 and i got no effect

Agree, there is some mistery behind it and at this point is hard to figure it
But im 100% sure the official firmware uses it, and there are some texts loading the value 11 from it (so is something small, not sure what, and the overrides are always related with sizes or positions)

I guess it belongs to a feature that is not displayed in your custom texts... not sure what could be but i mean things like the "glow" effect i mentioned before, it seems all the <Text> objects uses the glow, but in most of them is not visible

Im wondering if some of this extra features for <Text> objects are enabled by the textFontMode
Im going to copy what i wrote here for historical purposes https://www.psx-place.com/threads/ps3-pro-mod-release-information-thread.14641/page-40#post-208203

The thing i was going to suggest you next to align the texts is to change the value of textFontMode
Think in the value as composed by 4 bytes... and each byte is a different thing
In the <Text> object you posted in the forum you was using textFontMode="0x1000100"
Keep in mind rcomage removes the zeroes at left, so your textFontMode="0x1000100" is the same than textFontMode="0x01000100" (i added a zero at left to complete the 4 bytes)

Basically, is like this:
01 00 01 00 <---- this is what you was using

Time ago i was opening all the xml files from a single firmware, and using notepad++ i was counting how many times every value is used in OFW, this are the results

Valid values used in OFW's from PS3
01 00 00 00 (351 times) <---- this is used very frequently
01 00 00 01 (384 times) <---- this is used very frequently
01 00 01 00 (246 times) <---- this is used very frequently
01 00 01 01 (148 times)
01 01 00 00 (3 times)
01 01 00 01 (70 times)
01 01 01 01 (3 times)
01 00 00 02 (96 times)
01 00 01 02 (4 times)

Valid values used in OFW's from PSP
01 00 00 00 (415 times) <---- this is used very frequently
01 00 00 01 (240 times) <---- this is used very frequently
01 00 01 00 (27 times)
01 00 01 01 (325 times) <---- this is used very frequently
01 01 00 00 (19 times)
01 01 00 01 (279 times) <---- this is used very frequently
01 01 01 01 (14 times)
01 00 00 02 (21 times)
01 00 01 02 (14 times)
01 01 00 02 (3 times)


---------------
As you can see, most of the bytes only allows to use 0 or 1 (so they looks like switches ON/OFF)
The only exception seems to be the byte most at right, that allows to use the values 0, 1, and 2

Which value are you using for it ?, we should think in it as composed by 4 bytes, and every byte is a switch for a different feature, and all them are unknown

I think you should try to enable all bytes in it (by using value 0x01010101) and if everything looks ok you should keep using that value for all your custom <Text>
You know... the rule im following is... by enabling all features eventually you could find them... otherway with all disabled is imposible to find them

 

[sandungas]

Look, inside sysconf_plugin.rco

<Text name="text_parental_control_set_level" textFontMode="0x1000101" textOverrideUnk57="0x9a030100"></Text>

Take the first 2 bytes at left of the override value 0x9a030100 and "flip" them... so they becomes 0x039a
Then convert them to decimal... so they becomes 922
Then you add +1... so they becomes 923

Thats the line where is stored the value inside the layout .txt files, there is a .txt file for every resolution:
layout_grid_table1080.txt <----- at line 923 is stored the value 11
layout_grid_table720.txt <------ at line 923 is stored the value 7
layout_grid_table480.txt <------ at line 923 is stored the value 8
layout_grid_table272.txt <------ at line 923 is stored the value 8

----------------------
When you go to XMB settings column, and you change the screen resolution, the XMB resets, and the rco files loads the values for positions and sizes externally from this "layout" .txt files

 

[sandungas]

I will take a look at this =) nice finding, i will check the layout tables.

0x12000100 does not work but 0x13000010 works good, but still small , i will check some other values.


EDIT : changing0x12000100 to 0x12000010 works

Why some are 0x??????100 Others 0x??????010 ?

i will need to check how the overrides works in your post again :P

Good question

Btw, the override value 0x13000010 is ilegal, the reason why is working good for you in this case is because is not loading anything from the layout factor tables

In other words... the value 0x13000100 is loading something you dont like... and when you use 0x13000010 you are not loading that annoyance

This is long to explain, but as the most basic concept you need to think in the override values (composed by 4 bytes) as 2 values with 2 bytes each
So... to understand the value 0x13000010 you should split it in 2, first one is 0x1300, and second is 0x0010
Then you need to flip them, the first one is 0x13 and second one is 0x1000
Then convert them to decimal, and add + 1, and this is the line in the layout .txt files

The first one loads a value from line 20 of the layout_grid_table****.txt
The second one loads a value from line 4097 of the layout_factor_table****.txt <--- but the .txt file only have 143 lines

See the problem ?, you are trying to load a value from line 4097 of a .txt file that only have 143 lines... so the firmware cant load it

----------------------
The values i suggested like this one... 0x12000100
When you flip the bytes at right you have decimal 1... and when you do the +1 it means is going to load line 2 of the layour factor tables

First line in the factor tables is always storing the value 1 (and second line always stores a 0).... the values in the factor tables are used as multiplyers, and when you multiply something by 1 the result is the same
To achieve this you need to fill the 2 bytes most at right of the override with zeroes, like this:
0x12000000

To do the calculations, you need to flip the zeroes, then convert to decimal (so are still zeroes), and when you add a + 1 this is when it becomes the first line in the layout .txt files... in plain words, the value 0000 is loading line 1

This is like a golden rule needed to remember... the override values that ends with zeroes like this: 0x????0000 are loading a multiplyer = 1
And this is convenient for you because this way you should not worry about that multiplyers... in some way is like disabling the multiplyers

So you should use always 0x????0000... unless you really want to do something with that multiplyers

 

[sandungas]

I tested several values in the textFontSizeY="??" and it still does not affect anything

tested in the psp and it worked

Yes is weird, and thanks for the confirmation that it works in PSP, you made me doubt if the name textFontSizeY was wrong

I think this renaming i sugested is correct because both are doing the same

All the override attributes are specific for PS3 (the PSP doesnt even understands them). The purpose of them is to modify some of the other attributes in that same object that existed for PSP, most specifically the ones related with sizes or positions. So the actual attribute named textOverrideUnk56 could be modifying the other attribute named textFontSizeY. If this is true then the attribute named textOverrideUnk56 should be renamed to textOverrideFontSizeY

And actually... when i was making the override conversions of your post with the screenshot using different text sizes all them was matching with what you said
I mean... when you wrote a rough description of everyone of your tests based in the others liike... "this one is a big bigger than previous one"... or "this one is a bit smaller than next one"

To me this is a confirmation that you have identifyed that unknown
You are not much used to calculate that override values, but after the talks today i think you are going to get used to it fast and you are going to have good control of text sizes soon

 

[sandungas]

Btw @LuanTeles the oter day i made a couple of images about the anchorMode

anchorMode (known values)

​

anchorMode (unknown values)

​

 

[LuanTeles]

Btw @LuanTeles the oter day i made a couple of images about the anchorMode

anchorMode (known values)

​

anchorMode (unknown values)

​

The strange thing about the anchor mode is thar 0x3100 is the only one that makes the alignment not centered, but in the right side

 

[sandungas]

The strange thing about the anchor mode is thar 0x3100 is the only one that makes the alignment not centered, but in the right side

Not sure what you mean, but keep in mind the blue rectangle in my drawing represents an image (or a plane... or actually any object under <ObjectTree>)... but to simplify concepts we can say is a polygon made with 4 vertex

I used different colors for the "dots" to indicate the order how the firmware calculates his positions
The black dots are straightforward (no need to do any maths) because matches with the vertex of the polygon
The red dots are calculated next, the firmware does a simple math operation by dividing the side at half
And the yellow dot is a combination of the previous red dots

After that... the blue dots... all them are located externally to the polygon, this means as example... if you indicate coordinates x=10 and Y=40 and you use one of the blue dots the image is not going to be located in that position (it will be displaced a bit)

 

[sandungas]

...the actual attribute named textOverrideUnk56 could be modifying the other attribute named textFontSizeY. If this is true then the attribute named textOverrideUnk56 should be renamed to textOverrideFontSizeY

Im taking a look at xmb_plugin_normal.xml and just noticed another confirmation about this, the objects named <Text name="clock"> and <Text name="online_num"> are 2 texts everybody is used to them so we have a good idea of how they looks
Both appears inside the frame at top-right corner of the XMB, the clock is the text with the month/day/hours/minutes/... and the online_num is a tiny counter that appears at right of a small "friends" icon

There is a big difference of font sizes in between that texts, the clock uses a huge font, and the online_num is tiny... but his basic attributes are pretty much the same

<Text name="clock"      ... sizeX="0" sizeY="0" sizeZ="1" sizeScaleX="1" sizeScaleY="1" sizeScaleZ="1" ...  sizeOverrideX="0x0" sizeOverrideY="0x0" sizeOverrideZ="0x0" textMessage="nothing" textFontStyle="nothing" textFontMode="0x1000002" textUnk29="0x1" textFontSizeY="10" ...
<Text name="online_num" ... sizeX="0" sizeY="0" sizeZ="1" sizeScaleX="1" sizeScaleY="1" sizeScaleZ="1" ...  sizeOverrideX="0x0" sizeOverrideY="0x0" sizeOverrideZ="0x0" textMessage="nothing" textFontStyle="nothing" textFontMode="0x1000001" textUnk29="0x1" textFontSizeY="10" ...

The real difference is at the end of the xml line

<Text name="clock"      ...  textOverrideUnk56="0x13000000"
<Text name="online_num" ...  textOverrideUnk56="0x16000000"

The values needs to be splitted in 2 chunks of 2 bytes each... it works this way

The first 2 bytes of "clock" are loading the value from line number 0x13 of the XMB layout files (the "grid" version of that files, for the resolution of your TV)
The last 2 bytes of "clock" are loading the value from line number 0x0 of the XMB layout files (the "factor" version of that files, for the resolution of your TV)

Both values are used in a very tricky math formula that includes all the other attributes of the object related with position and sizes, in this case the formula is simple because the other values are either 0 or 1... so lets ignore the formula, in this example is very straightforward

We need to covert the value 0x13 to decimal... it results in 19... then add +1... and results in 20
The value stored in line 20 of the file "layout_grid_table_1080p" is 26... so the font used by "clock" have 26 pixels height

Now, for the text used by "online_num"... we convert the 0x16 to decimal = 22 + 1 = 23
The value stored in line 23 of the file "layout_grid_table_1080p" is 19... so the font used by "online_num" have 19 pixels height




Edit.
What a coincidence, i was taking a look at other stuff and found a nice image from the official manuals that shows how is build that frame

2) is the <Plane name="online"> that displays the icon with the attribute named planeImage="image:tex_indi_online", and the number at his right is the <Text name="online_num">
5) is the <Text name="clock">
7) is another <Text> "injected" by the sprx... this one doesnt exists in the rco

 

[sandungas]

Also, what @MeguminFanatic said here seems to be right

From that group of objects under <Page name="page_xmb_indicator"> the only one that uses the attribute planeResizeMode="0x3" is <Plane name="indi_base">
It seems to be because the sprx is resizing it dinamically and is "injecting" a <Text> object under it


Edit:
There are only 2 posible positions to "inject" the <Text> object, as a children of <Plane name="indi_base"> or as a children of <Plane name="indi_adjust">
Note both are "brothers" (because are located at the same height of the hierarchy), this means the transformations made in one of them doesnt affects the other
Visually "injecting" it in one or the other would look the same, so im not sure the exact position where that misterious <Text> is "injected"

That misterious <Text> object simply doesnt exists in the RCO, so we dont have any control of it in the RCO

Spoiler

At some point i was speculating if we could add this kind of missing objects in the rco to recover some control from the sprx
It coud be really handy, because we cant "recompile" sprx files to add/remove objects.... but adding/removing objects in rco files is doable

 

[sandungas]

Im "faking" the PS3 XMB accuratelly in photoshop and i realized about some interesting details

Distance X in between the centers of the icons "out of focus" = 200 px
Distance X in between the center of a icon "out of focus" and the center of the icon "on focus" = 210 px
Distance Y in between the center of the icon "on focus" and the center of the ICON0.PNG located below it = 215px

All the original icon images are 128x128px, the white ones from inside icontex.qrc and the PSN icon from an RCO
All the icons are scaled from his center located at x/2 and y/2 (this means "anchorMode=0") except the icon "on focus" where his anchor is located at x/2 and y/4 (i guess this means "anchorMode=20"... or... "anchorMode=40" ?)

The icons "out of focus" are using an scale factor around 0.94 (are reduced from the original 128x128 down to 120x120).. except the PSN icon that is reduced from the original 128x128 down to 118x118 so is using a scale factor around 0.92 (this is a dirty code fix specific for the PSN icon because it looks too big when compared with the others if we aply the same scale factor to all them)
The icon "on focus" is scaled from the original size 128x128 up to 168x168 so is using a scale factor around 1.32 but as mentioned before, this scalation is applyed with a displaced anchor located at 1/4 of his height, so it increases his size mostly in upper direction (this effect is distorting it btw, bad sony)

 

[sandungas]

@LuanTeles do you know if there is some rcoxml code where are defined that objects from my previous post ?
Right now im guessing this is made by a .sprx but im not sure
Incase that values appears in some xml i would like to review them to see how far away are from the values i said

Also, some of the values i mentioned should be loaded externally from the XMB Laouts because they needs to change dynamically for every screen resolution, the values i said only applyes to 1080p screen resolution

If someone wants to make some experiments with this... try to find the values i mentioned in the XMB layout files, modify them and see what happens

 

[LuanTeles]

@LuanTeles do you know if there is some rcoxml code where are defined that objects from my previous post ?
Right now im guessing this is made by a .sprx but im not sure
Incase that values appears in some xml i would like to review them to see how far away are from the values i said

Also, some of the values i mentioned should be loaded externally from the XMB Laouts because they needs to change dynamically for every screen resolution, the values i said only applyes to 1080p screen resolution

If someone wants to make some experiments with this... try to find the values i mentioned in the XMB layout files, modify them and see what happens

They are handled by a sprx.

The only thing i found that affects the XMB is

sizeScaleX="0.6" sizeScaleY="0.6" sizeScaleZ="1"

    <Page name="page_xmb_bg" pageMode="0x1101" pageOnInit="nothing" pageOnCancel="nothing" pageOnContext="nothing" pageOnActivate="nothing"></Page>
            <Page name="page_xmb" pageMode="0x1101" pageOnInit="nothing" pageOnCancel="nothing" pageOnContext="nothing" pageOnActivate="nothing">
                <XMenu name="xmenu" positionX="-395" positionY="40" positionZ="0" colorScaleR="1" colorScaleG="1" colorScaleB="1" colorScaleA="1" sizeX="0" sizeY="0" sizeZ="0" sizeScaleX="0.6" sizeScaleY="0.6" sizeScaleZ="1" anchorMode="0x0" onInit="event:native:/Bar::onInit" positionOverrideX="0x1010100" positionOverrideY="0x2010100" positionOverrideZ="0x3010100" sizeOverrideX="0x0" sizeOverrideY="0x0" sizeOverrideZ="0x0" xmenuItemNum="0xa" xmenuOnPush="event:native:/Bar::onPush" xmenuOnContext="event:native:/Bar::onContextMenu" xmenuOnCursorMove="event:native:/Bar::onCursorMove" xmenuOnScrollIn="event:native:/Bar::onScrollIn" xmenuOnScrollOut="event:native:/Bar::onScrollOut">
                    <XMList name="list_user" xmlistUnk1="0x0" xmlistImage="nothing" xmlistText="nothing"></XMList>
                    <XMList name="list_sysconf" xmlistUnk1="0x0" xmlistImage="nothing" xmlistText="nothing"></XMList>
                    <XMList name="list_photo" xmlistUnk1="0x0" xmlistImage="nothing" xmlistText="nothing"></XMList>
                    <XMList name="list_music" xmlistUnk1="0x0" xmlistImage="nothing" xmlistText="nothing"></XMList>
                    <XMList name="list_video" xmlistUnk1="0x0" xmlistImage="nothing" xmlistText="nothing"></XMList>
                    <XMList name="list_tv" xmlistUnk1="0x0" xmlistImage="nothing" xmlistText="nothing"></XMList>
                    <XMList name="list_game" xmlistUnk1="0x0" xmlistImage="nothing" xmlistText="nothing"></XMList>
                    <XMList name="list_network" xmlistUnk1="0x0" xmlistImage="nothing" xmlistText="nothing"></XMList>
                    <XMList name="list_psn" xmlistUnk1="0x0" xmlistImage="nothing" xmlistText="nothing"></XMList>
                    <XMList name="list_friend" xmlistUnk1="0x0" xmlistImage="nothing" xmlistText="nothing"></XMList>
                </XMenu>
            </Page>

is Where i messed to get a minismalistic XMB

The other attributes seems to be added and replaced by sprx.

I tried adding animation, changing it's position and etc but no effect

 

[sandungas]

Thx, it seems in the line you modifyed we are scaling the parent name="xmenu" and that scale affects all his children
And the scale factors i mentioned are specific for the children

Btw, the positionX="-395" (from the xml code you pasted) is the exact distance in between the center of the icon "on focus" and the center of the screen
And the positionY="40" (in the same xml line) should be a reference taken from the center of the icon "on focus" too... but a displacement of 40 pixels doesnt matches with the center of the screen... there is something more tricky related with it