Anyone Can Help with XML edits?

[dazzaXx]

The first thing you need to do is to keep in mind the value is composed by 2 groups of 2 bytes each (in other words "cut" the value at half)

What if the positionOverrideX and Y are "0x700"? or a 3 digit number?

 

[dazzaXx]

Btw @RandomDude im not sure if the xml line you pasted here is exactly what you was looking for
By the name of the object ("avatar_usrname") looks probable, but im not sure

Im going to eplain this in short...
The positionX, positionY, positionZ... are values inherited from PSP firmware
In a PSP the screen have always the same resolution... so the objects always uses the same positions and sizes

But in PS3 the XMB supports 4 screen resolutions, and every resolution needs to use different values for positions and sizes, this is why exists the "XMB layout" files, every layout belongs to a resolution and the PS3 loads only one layout
The values stored inside the XMB layout files "overrides" the values of positionX, positionY, positionZ (inherited from PSP)



So... the value of positionX is overrided by positionOverrideX (and so on for Y and Z... the same happens with sizes btw)
And this is the reason why positionX, positionY, and positionZ uses to be always 0

In other words... if you want to change the values of positions and sizes... what you need to modify is the "XMB layouts" (but there is no need to modify the RCO files, because the RCO files loads the values of positions and sizes "externally" from the XMB layouts)

Im going to show you an example with the values you posted in that line... what you need is to "translate" this values:
positionOverrideX="0x8e020000"
positionOverrideY="0x8f020000"
positionOverrideZ="0x0" <--- Z is zero, so lets forget about it

The first thing you need to do is to keep in mind the value is composed by 2 groups of 2 bytes each (in other words "cut" the value at half)
positionOverrideX = 8e02 (first group) and 0000 (second group)
positionOverrideX = 8f02 (first group) and 0000 (second group)

The second group is unknown... so forget about it (if someone finds how works the second group please post it in wiki)

Both groups needs the bytes to be "flipped" (because the PS3 and PSP processors uses different endianess), keep attention at how im flipping them !
positionOverrideX = 028e
positionOverrideX = 028f

Now is needed to convert them to decimal (use a calculator, hexadecimal to decimal) and add a +1
positionOverrideX = 654 + 1 = 655
positionOverrideX = 655 + 1 = 656

Now open the "XMB layout" files in notepadd++ and look at the values in lines 655 and 656, this is what you need to change
dev_flash/vsh/etc/layout_grid_table_1080.txt <--- this one is for 1920x1080 pixels screen resolution

If you want to release a mod publically you should change it too for the other resolutions, just because you dont know which TVs and which resolutions other people is using
Anyway... you should change the values in all resolutions even if is not a public release just incase you have some problem with the TV or you connect the PS3 in other display with other resolutions... is mostly a "just incase"

Here's a thought, since the position overrides are hexidecimal pointers to which number line it reads off of, couldn't you simply add in your own override for a specific plane that doesnt have one and work out the hexidecimal for it?

 

[sandungas]

Apparently -dxt5 isn't working, tried checking the conf file & ps3dxt5 is there. Tried -ps3dxt5 & it worked perfectly. Might need to update rcomage i think @sandungas

You mean in the config of gimconv, right ?
Is made like that on purpose, what happens is the option -dxt5 (used alone without other options) is not enought for PS3. By using the option -dxt5 alone gimconv also uses some of the other "default" options (located at top)
If you look in the config at the -ps3dxt5 option you will see it contains more options, this ones are critical

What if the positionOverrideX and Y are "0x700"? or a 3 digit number?

Im going to write some examples, i think wil be better than a explaination

0x34120100 = 0x1234 (group1) and 0x1 (group 2)
0x23010000 = 0x123 (group1) and 0x0 (group 2)
0x12000100 = 0x12 (group1) and 0x1 (group 2)
0x120000 = 0x1200 (group1) and 0x0 (group 2)
0x10100 = 0x1000 (group1) and 0x1 (group 2)

The only posible values ive found for the second group are 0 or 1... so it seems to be something simple, probably related with the other "xmb layouts" named "factor table"

Here's a thought, since the position overrides are hexidecimal pointers to which number line it reads off of, couldn't you simply add in your own override for a specific plane that doesnt have one and work out the hexidecimal for it?

Not sure if i understood you correctly, but i think the answer is yes, i never tryed it but it should work
Lets say... the official file dev_flash/vsh/etc/layout_grid_table_1080.txt have 4321 lines... you can add a custom value at line 4322 and then make the reverse calculation

4322 -1, then converted to hex (0x10e1), then flipped, then added the group at the right (initially with 0, and incase it doesnt works with 1)

0xe1100000
or...
0xe1100100

 

[sandungas]

Btw... there are lot of RCO files that loads the values from the same line of the "XMB layout" than other RCO files
If there is a value used by several RCO files, the firmware allows to store the value a single time inside the "XMB layouts"
We could consider is made this way for efficiency, but there are lot of values repeated inside the "XMB layouts"... so the only fact is some RCO files "shares" values and some doesnt
Another mistery unsolved :P

The point is... if you want to store some custom value the first thing you can do is to make a search in the "XMB layouts" because maybe it exists already, so there is no need to customize the "XMB layouts" for this value
Anyway... if what you are doing requires lot of values i guess is fine to add a bunch at the end

 

[RandomDude]

You mean in the config of gimconv, right ?
Is made like that on purpose, what happens is the option -dxt5 (used alone without other options) is not enought for PS3. By using the option -dxt5 alone gimconv also uses some of the other "default" options (located at top)

-dxt5 is invalid it says, although -ps3dxt5 works...


also I tried with coordinates 400, 400.. to display a simple text and it fails. What if rcomage actually uses local coordinates?

 

[Cypher_CG89]

Does the PS3dxt5 gim setting let it show on the xmb ? or white box?

 

[RandomDude]

Does the PS3dxt5 gim setting let it show on the xmb ? or white box?

It does display it on the xmb without white box for tex_psn.png and tex_icon_loading.png

It's a pain in the ass to check the original gim file settings and compare for difference in thier file hashes

 

[sandungas]

-dxt5 is invalid it says, although -ps3dxt5 works...


also I tried with coordinates 400, 400.. to display a simple text and it fails. What if rcomage actually uses local coordinates?

Ok, i been checking it and you are right, what i said before is because i thought (from memory) that inside GimConv.cfg exists an option named -dxt5, but i been looking at all the GimConv.cfg (official, rcomage, and mine) and doesnt exists an specific option for it

What i found is i had a typo in the small tutorial posted here, for the command i suggested for "try3"
http://www.psx-place.com/threads/research-rcomage-psdevwiki-mod.17958/#post-123800

Btw, there is no need to remember the commands from memory... the next time you need to repeat that GIM settings identification process you can run gimconv.exe without any options and it will show you the "help" screen with this:

	puts "examples GIM-to-GIM:"
	puts "         gimconv original.gim -o try1.gim -ps3rgba8888"
	puts "         gimconv original.gim -o try2.gim -ps3rgba8888 --update_fileinfo on"
	puts "         gimconv original.gim -o try3.gim -ps3dxt5"

Thanks for advising me, i fixed the typo in the tutorial, the good news is the RCOmageMOD is fine, there is no need to update it because was not affected by this typo

 

[sandungas]

also I tried with coordinates 400, 400.. to display a simple text and it fails. What if rcomage actually uses local coordinates?

Sorry if what i mentioned before could confuse you, but all the coordinates are local
In other words, are dependant of the coordinates of his parent/s

Better explained with an example... lets say we have this hierarchy

<ObjectTree>
---object_1 (using positionOverrideX = 40)
------object_2_1 (using positionOverrideX = 10)
---------object_3 (using positionOverrideX = 5)
------object_2_2 (using positionOverrideX = -60)

You can consider the coordinates of object_1 as global, because are not affected by any other object
object_2_1 (displayed at X = 50) and object_2_2 (displayed at X = -20) are "brothers", and also are "childrens" of object_1
object_3 (displayed at X = 55) inherits the coordinates of object_1 and object_2_1


--------------------
Also, the position is dependant of the anchorMode
The best way to understand this is if you open an image editor (like photoshop), make a circle selection and the tab: Edit--->transform--->rotate
You are going to see a "handler point" located in the center of the circle (by default but you can move it before starting the rotation)

In the PS3 it works like that too, and there are some predefined values for the anchorMode
https://www.psdevwiki.com/ps3/RCOXML_Objects#Standard_attributes_used_by_objects
The biggest difference with what i explained in photoshop is all the images are squares (or rectangles), so that points are located geometrically to map an square (there is 1 for the center of the square, 4 for the corners, another 4 for the center of the sides, etc...). Sadly some of them are unknown :/

But yeah... as you can imagine the location of this anchorMode is important because affects where the object is displayed on screen

 

[RandomDude]

A typo still remains for try 3....

Thanks for advising me, i fixed the typo in the tutorial, the good news is the RCOmageMOD is fine, there is no need to update it because was not affected by this typo

You might need to edit the .txt files in DOCS:

Btw Tysm for helping out.

 

[dazzaXx]

Lets say... the official file dev_flash/vsh/etc/layout_grid_table_1080.txt have 4321 lines... you can add a custom value at line 4322 and then make the reverse calculation

4322 -1, then converted to hex (0x10e1), then flipped, then added the group at the right (initially with 0, and incase it doesnt works with 1)

0xe1100000
or...
0xe1100100

That was my exact thought, and i can confirm it does work, you are indeed able to add your own X and Y overrides into the grid layout and point it to a specific UI plane.

EDIT: Well, i have and it has moved the plane, but i feel it's just made it go to 0, 0 because whenever i increase the override, it remains in the same position.

 

[sandungas]

A typo still remains for try 3....

Ops, now i fixed it in the forum

You might need to edit the .txt files in DOCS:

Auch, this hurts because i will need to make a new release to fix that... is just a tutorial (so not a critical bug) but is important
Not sure what to do, before this it happened that i imagined to make another minor changes (not important, but small improvements imo), not worthy for a new release, but worthy to be added at the time a new release happens (because something important was found)

I think im going to add a list of "planned changes for the next release" in post #3 to keep a record and dont forget about it http://www.psx-place.com/threads/research-rcomage-psdevwiki-mod.17958/#post-123801

Btw Tysm for helping out.

Thanks to you for finding the problems

That was my exact thought, and i can confirm it does work, you are indeed able to add your own X and Y overrides into the grid layout and point it to a specific UI plane.

Nice
Another thing you could do is to create a special object named group at a intermediate level of the hierarchy (with lot of objects under it), and then move the group object, this way you can move a group of objects without "breaking" his local positions

The object "group" is special because doesnt have any specific attributes, and doesnt displays anything on screen

 

[dazzaXx]

Nice
Another thing you could do is to create a special object named group at a intermediate level of the hierarchy (with lot of objects under it), and then move the group object, this way you can move a group of objects without "breaking" his local positions

The object "group" is special because doesnt have any specific attributes, and doesnt displays anything on screen

So what i did was split up "page_xmb_indicator" into two parts and made my own group with custom names since those are the only ones i want to move, but it seems to have made the UI elements dissapear.

 

[RandomDude]

So what i did was split up "page_xmb_indicator" into two parts and made my own group with custom names since those are the only ones i want to move, but it seems to have made the UI elements dissapear. View attachment 15061View attachment 15060

Where'd you figure out the x and y coordinates from?

 

[sandungas]

So what i did was split up "page_xmb_indicator" into two parts and made my own group with custom names since those are the only ones i want to move, but it seems to have made the UI elements dissapear. View attachment 15061View attachment 15060

Have you tryed this way ?

Edit:
Ops, the name Group needs to be written starting in uppercase
Incase of mistakes rcomage will advise you with a warning indicating the name is wrong, some attribute of it is missing or have an incorrect data type
Incase of doubts take a look at the object definitions, inside objattribdef-ps3.ini

 

[dazzaXx]

Have you tryed this way ?

Just to confirm, is the group tag the same as a plane? with all the positions and color scales, etc.?

EDIT: I've never used </Group> or heard of it before so im just double checking, i didn't even know "group" was a tag that was usable xD

 

[dazzaXx]

Where'd you figure out the x and y coordinates from?

I didn't, those are the stock co-ordinates that were already there if you mean the positionX and Y.

 

[sandungas]

I was editing the post to explain it
You can see all the object names, followed by the attribute names used by that object, and his data types inside objattribdef-ps3.ini
Also, in this page of psdevwiki: https://www.psdevwiki.com/ps3/RCOXML_Objects#.280x812.29_Group

 

[dazzaXx]

I was editing the post to explain it
You can see all the object names, followed by the attribute names used by that object, and his data types inside objattribdef-ps3.ini
Also, in this page of psdevwiki: https://www.psdevwiki.com/ps3/RCOXML_Objects#.280x812.29_Group

Right, that worked, making progress now

 

[dazzaXx]

@sandungas Took me ages but i managed it in the end xD moved the clock UI from the top right all the way to the bottom left, but i had to use pre-set override coordinates that were already in the layout grid txt file because it seems when i tried using custom ones i put in, it didn't like that.

Just gotta figure out how to make it revert to normal when it goes 720p or below.