Talk:Rcomage: Difference between revisions

From PS3 Developer wiki
Jump to navigation Jump to search
m (→‎objattribdef-ps3.ini: from sysconf_plugin.rco)
 
(39 intermediate revisions by the same user not shown)
Line 1: Line 1:
=rcomage innacuracies, mistakes, bugs, or unsupported rco specifications=
==Rebuild verification==
There is an easy way to verify if the building methods used by rcomage are exactlly like the ones used officially by sony, it basically consists in rebuilding an official rco, the hashes of the original and rebuilt .rco should match exactlly... in other words, after the rebuild the .rco file should be exactlly like the original
*Requirements for this to work
**the files needs to be extracted in "raw" format (if using "rcomage gui" in the DUMP tab uncheck all the checkboxes for GIM, VAG, VSMX)... long story short this is to avoid mistakes with the conversors
**the rco TOC (aka what rcomage names "header compression") needs to use the same compression method than the original (if using "rcomage gui" in the COMPILE tab choose the correct "header compression" from NONE, ZLIB, RLZ)
***rcomage doesnt keeps a record of this "header compression", so the way to identify it is by opening the original .rco in a hexeditor and check the value stored at absolute offset 0xC. See [[Resource Container (RCO)]]
This method is specially usefull with the .rco files that doesnt have "header compression" because is easyer to find the differences in a hexeditor, oldest PS3 firmware .rco's (like the ones in firmware 1.02) are not compressed
==official dummy language string pointers not managed by rcomage==
Found in '''xmb_plugin_normal.rco''' firmware 1.02 (and probably most others using language text strings, is just in this one is more obvious where the problem happens)
*xmb_plugin_normal.rco firmware 1.02 original and rebuild at absolute offset 0x50, is indicating the language pointers table starts at absolute offset '''0x7EC''' (position is the same in both, original and rebuild)
**but the size (indicated at offset 0x54) in original is 0x90... and in rebuild 0x78 (after rebuild is smaller, rcomage has "lost" some bytes from it)
The table contains the pointers for every text string for every language, PS3 firmware 1.02 supports up to 10 languages, and every language contains 3 text strings... this makes a total of 30 pointers, every pointer is 4 bytes size, so the whole table of language text pointers should be 120 bytes length (0x78 in hex)... this is what rcomage does
But sony added 6 more pointers to the end of the table (of 4 bytes length each) all filled with zeroes... can be considered padding, but also can be considered "dummy pointers" because belongs to the table of pointers
Now... the question (and the reason why rcomage doesnt adds this pading) is.... '''why sony added that "dummy pointers" ?'''
illuminati event one, theory one (in the track)
-----------------------------------------------
<sandungas> just found an "innacuracy" of rcomage when rebuilding files
<sandungas> im not calling it a mistake because it doesnt breaks the format
<sandungas> is an (seems stupid) padding sony adds in the original files.... but rcomage doesnt
<sandungas> the point is maybe is not so stupid and is based on how the contents are mounted in the console ram, aligned to memory blocks and stuff like that
<sandungas> actually, maybe this is dependant of the console (ps3 or psp) because the different ram management, hmmmm
<zecoxao_> you need ZingaBurga
<sandungas> yep :/
<sandungas> and i remember him talking about this
<sandungas> someone asked him why the rebuilding was not perfect... and he mentioned some "weird" padding sony did but he could not understand why it happens
<sandungas> i think i know why :)
<sandungas> is a dirty trick, not efficient because adds additionally unneeded padding, but assures you the text pointers are aligned properlly without need to make complex calculations
<sandungas> something like this...
<sandungas> if total numer of languages inside .rco is not multiple of 4..... add "dummy" languages until it reaches a multiple of 4
*It needs to be verifyed further in other .rco files but my theory is this: --[[User:Sandungas|Sandungas]] ([[User talk:Sandungas|talk]]) 00:56, 21 September 2016 (UTC)
**the table of pointers needs to be aligned to 0x10 bytes boundary (from the start of the table itself), but trying to calculate the padding before building the file is a pita (because there can be lot of languages and lot of text strings for every language, is needed to read every text, multiply by language number, then calculate padding, etc... is not efficient)... so they decided to add this "blind alignment prevention". The thing consists in creating the table by cummulating "pointer placeholders" that contains ALWAYS groups of pointers that are a multiple of 4 based in the number of languages stored inside the .rco (this way the number of strings for every language doesnt matters at all, the table will always be aligned to 0x10 bytes)
**As example, in the worst scenario posible... if the rco only contains one language, and only one text string for that language... at building time the table of pointers is created with a size of 0x10 bytes (to store 4 pointers for 4 languages minimal)... then the first pointer is filled... and because there are not more pointers to store the other areas are kept filled with zeroes
**Another example, with 5 languages... the table is created for 8 languages (rounded to the next multiple of 4) so "pointer placeholders" are added to the table in groups of eight
***In the first step the table has room for 8 pointers and is filed with the 5 pointers for the first text string... now is calculated how many "pointer placeholders" are left in the table = 3... so the table is increased in size with 8 "pointer placeholders" more... now the table has 11 available "pointer placeholders" and are filled with the 5 pointers for the second string stored in positions 6 up to 10... now is calculated how many "pointer placeholders" are left in the table = 1... so the table is increased in size with 8 "pointer placeholders" more... and so on
***Note the number of strings doesnt matters (not needed to know, is not a variable in the function), the process is repeated in a loop and the table will always be aligned to 0x10 bytes boundary
*In PS3 xmb_plugin_normal.rco from firmware 1.02 (with 10 languages) the "pointer placeholders" that are cummulated to make the table bigger (needs to be bigger than 10 and a multiple of 4) are added in groups of 12 pointers (chunks of 0x30 bytes). In the original file the table has a size of 0x90 bytes, this means the table has been increased in size 3 times in the .rco building process
*There are other innacuracies when rebuilding this file... not sure if are related with text strings too though... are hard to see where is the problem because the areas are displaced by the problem explained above
**as example... the last event in the "events table" in original is '''native:/Bar::onCursorMove''' (seems to be stored in a different order)
==RCO format version 0x93 (used by PS3 firmware 082.006)==
There is a problem with the "Image" entries (located under "ImageTree") on the TOC. At the time sony "ported" the RCO format from PSP-to-PS3 it was added an additional value for "Image" (usually a 0x1 and his purpose is still unknown). This additional value was added at pre-retail DECR 085 series (rco_version 0x97). More info here: [[RCOXML_Images#Image]]
The firmwares affected are all PS3 pre-retail 082, 083, and 084 series
Fix for rcomage: if endianess = big and rco_version < 0x97 this value doesnt exists
==RCO format version 0x55 (used by PSP firmware 0.6.5)==
PSP firmware 0.6.5 uses a primitive version of the rco format, this is an example of the rco header (first 0x94 bytes) of '''system_plugin.rco''', most notable change is the header is smaller (so is missing some areas for features that was not implemented yet). I dont plan to look for all the changes but this little example hopefully will show what areas are missing to have an overall idea of the order of how features was implemented in the rco format. This version of the rco format is not compatible with rcomage... <strike>but it should by deleting the "unknowns" in the definitions of the source code (lines 51 and 76 of rcofile.h) then compile it (not tested, other errors can happen but this should work)</strike> the idea doesnt works, compiler returns other errors http://paste.ubuntu.com/23207840/
Original header (remember PSP uses little endian so some bytes are swapped)
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000  00 50 52 46 55 00 00 00 00 00 00 00 00 00 00 00  .PRFU...........
00000010  94 00 00 00 FF FF FF FF 7C 0A 00 00 34 08 00 00  ”...ÿÿÿÿ|...4...
00000020  FF FF FF FF BC 00 00 00 FF FF FF FF 7C 0B 00 00  ÿÿÿÿ¼...ÿÿÿÿ|...
00000030  FF FF FF FF E0 0C 00 00 68 00 00 00 48 0D 00 00  ÿÿÿÿà...h...H...
00000040  9C 04 00 00 E4 11 00 00 04 00 00 00 F0 0B 00 00  œ...ä.......ð...
00000050  28 00 00 00 18 0C 00 00 94 00 00 00 FF FF FF FF  (.......”...ÿÿÿÿ
00000060  00 00 00 00 AC 0C 00 00 2C 00 00 00 D8 0C 00 00  ....¬...,...Ø...
00000070  08 00 00 00 FF FF FF FF 00 00 00 00 E8 11 00 00  ....ÿÿÿÿ....è...
00000080  40 DF 01 00 28 F1 01 00 F0 58 02 00 FF FF FF FF  @ß..(ñ..ðX..ÿÿÿÿ
00000090  00 00 00 00                                      ....
{| class="wikitable" style="font-size:x-small;"
|-
! Areas !! Offset !! Length !! Example !! Name !! Notes
|-
| rowspan="43" | Header
|-{{cellcolors|#666666|#ffffff}}
| 0x00 || 0x04 || PRF || '''magic''' || PRF in little endian
|-{{cellcolors|#666666|#ffffff}}
| 0x04 || 0x04 || 55 00 00 00 || '''version''' || 0x55 = one of the firmwares for PSP
|-{{cellcolors|#666666|#ffffff}}
| 0x08 || 0x04 || 00 00 00 00 || ''unknown'' ||
|-{{cellcolors|#666666|#ffffff}}
| 0x0C || 0x04 || 00 00 00 00 || '''compress_header''' || 0x00 = uncompressed
|-{{cellcolors|lightgrey}}
| colspan="5" |
|-
| 0x10 || 0x04 || 94 00 00 00 || '''toc_maintree_absolute_offset''' || MainTree at absolute offset 0x94
|-
| 0x14 || 0x04 || FF FF FF FF || '''toc_scripttree_absolute_offset''' ||
|-
| 0x18 || 0x04 || 7C 0A 00 00 || '''toc_languagetree_absolute_offset''' || TextTree at absolute offset 0xA7C
|-
| 0x1C || 0x04 || 34 08 00 00 || '''toc_soundtree_absolute_offset''' || SoundTree at absolute offset 0x834
|-
| 0x20 || 0x04 || FF FF FF FF || '''toc_modeltree_absolute_offset''' ||
|-
| 0x24 || 0x04 || BC 00 00 00 || '''toc_imagetree_absolute_offset''' || ImageTree at absolute offset 0xBC
|-
| 0x28 || 0x04 || FF FF FF FF || {{cellcolors|#ff7777}} ''toc_unknowntree_absolute_offset'' or '''toc_fonttree_absolute_offset'''||
|-
| 0x2C || 0x04 || 7C 0B 00 00 || '''toc_objecttree_absolute_offset''' || ObjectTree at absolute offset 0xB7C
|-
| 0x30 || 0x04 || FF FF FF FF || '''toc_animationtree_absolute_offset''' ||
|-{{cellcolors|lightgrey}}
| colspan="5" |
|-
| 0x34 || 0x04 || E0 0C 00 00 || '''strings_texts_absolute_offset''' || strings texts table at absolute offset 0xCE0
|-
| 0x38 || 0x04 || 68 00 00 00 || '''strings_texts_length''' || strings texts table size 0x68
|-
| 0x3C || 0x04 || 48 0D 00 00 || '''strings_labels_absolute_offset''' || strings labels table at absolute offset 0xD48
|-
| 0x40 || 0x04 || 9C 04 00 00 || '''strings_labels_length''' || strings labels size 0x49C
|-
| 0x44 || 0x04 || E4 11 00 00 || '''strings_events_absolute_offset''' || strings events table at absolute offset 0x11E4
|-
| 0x48 || 0x04 || 04 00 00 00 || '''strings_events_length''' || strings events size 0x4
|-{{cellcolors|lightgrey}}
| colspan="5" |
|-
| 0x4C || 0x04 || F0 0B 00 00 || '''text_pointer_table_offset''' ||
|-
| 0x50 || 0x04 || 28 00 00 00 || '''text_pointer_table_length''' ||
|-
| 0x54 || 0x04 || 18 0C 00 00 || '''image_pointer_table_offset''' ||
|-
| 0x58 || 0x04 || 94 00 00 00 || '''image_pointer_table_length''' ||
|-
| 0x5C || 0x04 || FF FF FF FF || '''model_pointer_table_offset''' ||
|-
| 0x60 || 0x04 || 00 00 00 00 || '''model_pointer_table_length''' ||
|-
| 0x64 || 0x04 || AC 0C 00 00 || '''sound_pointer_table_offset''' ||
|-
| 0x68 || 0x04 || 2C 00 00 00 || '''sound_pointer_table_length''' ||
|-
| 0x6C || 0x04 || D8 0C 00 00 || '''object_pointer_table_offset''' ||
|-
| 0x70 || 0x04 || 08 00 00 00 || '''object_pointer_table_length''' ||
|-
| 0x74 || 0x04 || FF FF FF FF || '''anim_pointer_table_offset''' ||
|-
| 0x78 || 0x04 || 00 00 00 00 || '''anim_pointer_table_length''' ||
|-{{cellcolors|lightgrey}}
| colspan="5" |
|-
| 0x7C || 0x04 || E8 11 00 00 || '''image_data_section_offset''' ||
|-
| 0x80 || 0x04 || 40 DF 01 00 || '''image_data_section_length''' ||
|-
| 0x84 || 0x04 || 28 F1 01 00 || '''sound_data_section_offset''' ||
|-
| 0x88 || 0x04 || F0 58 02 00 || '''sound_data_section_length''' ||
|-
| 0x8C || 0x04 || FF FF FF FF || '''model_data_section_offset''' ||
|-
| 0x90 || 0x04 || 00 00 00 00 || '''model_data_section_length''' ||
|-{{cellcolors|#ff7777}}
| colspan="5" | 12 bytes of unknowns 0xFF's was added here for newer versions of the rco format
|}


=Missing descriptors in rcomage current version (1.1.1)=
=Missing descriptors in rcomage current version (1.1.1)=
Line 12: Line 182:
  [languages]
  [languages]
  00_Japanese      ; ja
  00_Japanese      ; ja
  01_English_US    ; us
  01_English_US    ; en
  02_French        ; fr
  02_French        ; fr
  03_Spanish        ; es
  03_Spanish        ; es
Line 33: Line 203:
*changes
*changes
**Added the 4 unknown languages (Polish, Portuguese_BR, English_GB, Turkish)
**Added the 4 unknown languages (Polish, Portuguese_BR, English_GB, Turkish)
**Added "2 digits language code" before name, and language variant after name
**Added "two-digit" language code before name, and language variant after name
**Changed names for variants of English_US/GB, Portuguese_PT/BR, and Chinese_T/S
**Changed names for variants of English_US/GB, Portuguese_PT/BR, and Chinese_T/S
**Changed commented languages to "2 letters language code" standards<!-- taken from "string viewer plugin" iirc-->
**Changed commented languages to "two-letter" language code, from explore_plugin.sprx
**Fixed "Portugese" typo
**Fixed "Portugese" typo
==tagmap.ini==
This file defines the names of the tags used in the XML descriptor at the root of the .rco
Only 2 unknowns:
[Object]
ObjUnknown0xB
ObjUnknown0x1B
==animattribdef-ps3.ini==
This file defines the names of the animation attributes used in the XML descriptor at the root of the .rco
Only 5 unknowns. It seems that unknownInt5, unknownInt6, unknown7 has been implemented with rco 2.0 format specifically for PS3 (not supported in PSP). The others for lock/unlock existed before in rco 1.0 format (supported in PSP)
[MoveTo]
unknownInt5 = int
unknownInt6 = int
unknown7 = unk
[Lock]
unknownInt0 = int
[Unlock]
unknownInt0 = int


==objattribdef-ps3.ini==
==objattribdef-ps3.ini==
This file defines the names of the object attributes used in the XML descriptor at the root of the .rco
This file defines the names of the object attributes used in the XML descriptor at the root of the .rco


Lot of unknowns, some of them was not posible to identify in PSP times because PSP never used them... but in PS3 is posible to identify a few more, please help to fill an "unnofficial" list here
onInit, onPush, buttonPush, btnClick, onButton, onLoad... sometimes are used as a generic "run" command and can replace any of the other events (as example on some menues of xmb settings column when moving right is taken as a push) so is hard to identify the official name that are replacing. For this reason the list here keeps some counters of how many times have been found in official firmware. The counters works as a justification of why some names has been changed based in the number of times used
 
onPanelCommand seems to be an special event that can replace some of the standard events (used as a ''Button'' attribute)
 
===Standard object attributes===
; -- BEGIN STANDARD POSITION DEFINITION --
onLoad          onInit <---------- used 5485 times in 4.76 firmware, most with "OnInit" or "nothing"
; -- END STANDARD POSITION DEFINITION --
 
===Specific object attributes===
  [Page]
  [Page]
unknownInt0  ???????? <---- used 1174 times in retail firmware 4.76 all them with value: 0x1110000<!-- page objects are the most importants because are the parents of the others and this attribute is located in the first position because is prioritary for efficiency purposes (seems to be something needed to be readed by the firmware as soon as posible to decide what to do with his childrens), probably related with some execution mode of the firmware, target_id, enviroments, or something like that-->
  onInit        <------------- used 625 times in firmware 4.76. Around 607 onInit, 18 onOpen
  onInit        <------------- used 625 times in firmware 4.76. Around 607 onInit, 18 onOpen
  onContextMenu onContext <--- better to use a more generic name because "onContext" is used in several other objects and is technically the same event for all them
  onContextMenu onContext <--- better to use a more generic name because "onContext" is used in several other objects and is technically the same event for all them
Line 58: Line 261:
  unknownEvent43 onFocusDown
  unknownEvent43 onFocusDown
  unknownEvent45 onContext
  unknownEvent45 onContext
unknownInt47  ?????????????? <--- used 624 times in firmware 4.76 with values: 0x0 (560 times), or 0xffffffff (64 times)
   
   
  [XMenu]
  [XMenu]
  onEnter        onPush <---- used 2 times in firmware 4.76. Both onPush
  onEnter        onPush <---- used 2 times in firmware 4.76. Both onPush
  unknownEvent28 onCursorMove
  unknownEvent28 onCursorMove
  onLabelLoad    onScrollIn <---- better, official name
  onLabelLoad    onScrollIn <---- official name
  unknownRef32  onScrollOut
  unknownRef32  onScrollOut
   
   
  [XMList]
  [XMList]
unknown0      ???????? <---- used 20 times in firmware 4.76 all them with value 0x0 (the 10 main XMB icons in xmb normal/ingame)
  unknownRef3    text
  unknownRef3    text
   
   
  [XList]
  [XList]
  unknownInt23 <-------- used 18 times in firmware 4.76 all them with value 0x0
  onMove        onCursorMove <---- official name (is the same, but this way matches with the others)
unknownEvent36 <------ used 18 times in firmware 4.76 all them with value "nothing"
   
   
  [Progress]
  [Progress]
  unknownRef25  image
  unknownRef25  image
  unknownRef27  image2 <------ shadow image ?
  unknownRef27  image2 <------ shadow image ?
unknownRef29  ????????  <------ focus image ?
   
   
  [MList]
  [MList]
unknownRef32 ??????
  unknownRef33 onPush
  unknownRef33 onPush
  unknownRef35 onCursorMove
  unknownRef35 onCursorMove
Line 106: Line 304:
  unknownEvent33  onDecide
  unknownEvent33  onDecide
  unknownEvent35  onCancel
  unknownEvent35  onCancel
unknownRef37    ???    <-------
unknownRef39    ???    <-------
  unknownRef41    onFocusIn
  unknownRef41    onFocusIn
  unknownRef43    onFocusOut
  unknownRef43    onFocusOut
Line 115: Line 311:
  [LList]
  [LList]
  unknownEvent40  OnScrollIn
  unknownEvent40  OnScrollIn
unknownRef42    OnScrollOut    <------- speculative
   
   
  [Edit]
  [Edit]
  unknownEvent31  onDecide
  unknownEvent31  onDecide
  unknownRef33    onCancel
  unknownRef33    onCancel
unknownRef35    ???    <------- OnRollIn ?
unknownRef37    ???
  unknownEvent39  onFocusLeft
  unknownEvent39  onFocusLeft
  unknownEvent41  onFocusRight
  unknownEvent41  onFocusRight
  unknownObject43 object2 ?
  unknownObject43 object1
  unknownObject45 object2 ?
  unknownObject45 object2
   
   
  [Clock]
  [Clock]
Line 132: Line 325:
  unknownEvent33  onDecide
  unknownEvent33  onDecide
  unknownEvent35  onCancel
  unknownEvent35  onCancel
unknownRef37    ???    <-------
unknownRef39    ???    <-------
  unknownEvent41  onFocusLeft
  unknownEvent41  onFocusLeft
  unknownEvent43  onFocusRight
  unknownEvent43  onFocusRight
unknownRef45    ???    <-------
unknownRef47    ???    <-------
  unknownEvent49  onTickClock <!--ticks from system timer ?-->
  unknownEvent49  onTickClock <!--ticks from system timer ?-->
   
   
  [IList]
  [IList]
unknownRef25    ???    <-------
unknownRef27    ???    <-------
  unknownEvent29  onFocusLeft
  unknownEvent29  onFocusLeft
  unknownRef31    onFocusRight
  unknownRef31    onFocusRight
unknownRef33    onFocusUp ? <-------  speculative
  unknownRef35    onFocusDown
  unknownRef35    onFocusDown
  unknownRef37    onPush <------------ found used this way (and only 1 time in firmware 4.76), but it seems OnPush is used here as a generic event
  unknownRef37    onPush <------------ found used this way (and only 1 time in firmware 4.76), but it seems OnPush is used here as a generic event
   
   
  [IItem]
  [IItem]
unknown1      ???????? <---- used 136 times in firmware 4.76 all them with value 0x0
  textDefault    text
  textDefault    text
  textError      altText  <---- because is not an error strictlly
  textError      altText  <---- because is not an error strictlly
[UButton]
onLeft        onFocusLeft  <----- official name
onRight        onFocusRight  <---- official name
onUp          onFocusUp  <------- official name
onDown        onFocusDown  <----- official name
   
   
  [CheckboxGroup]
  [CheckboxGroup]
  unknownRef33    onPush
  unknownRef33    onPush     <---- used 23 times in 4.76 firmware, 17 onPush, the others "nothing"
  unknownRef35    onCursorMove
  unknownRef35    onCursorMove
  unknownRef37    onFocusIn
  unknownRef37    onFocusIn
Line 164: Line 355:
  unknownRef47    onFocusDown
  unknownRef47    onFocusDown
  unknownRef49    onScrollIn
  unknownRef49    onScrollIn
unknownRef51    onScrollOut ? <------- speculative, is the last attribute of "checkbox" group
   
   
  [CheckboxItem]
  [CheckboxItem]
  unknownRef1    text
  unknownRef1    text
unknownRef3    ???
unknownRef5    ???
   
   
  [EditBox]
  [EditBox]
  unknownRef59  image <--------- name is too generic, is better a more explicit name as "shadow"
  unknownRef59  image
  unknownRef61  image2  <--------- name is too generic, is better a more explicit name as "glow"
  unknownRef61  image2
unknownRef63  onClick
unknownRef63   onPush      <---- used 74 times in 4.76 firmware, 62 onPush, 1 onBtnClick, 11 "nothing"
  unknownRef65  onFocusIn
  unknownRef65  onFocusIn
  unknownRef67  onFocusOut
  unknownRef67  onFocusOut
Line 181: Line 369:
  unknownRef73  onFocusUp
  unknownRef73  onFocusUp
  unknownRef75  onFocusDown
  unknownRef75  onFocusDown
<!-- STANDARD POSITION DEFINITION
onLoad        onInit <---- better, official name (in rcomage are swapped onInit & onLoad)
-->


*Examples:
*Examples:
Line 250: Line 434:
**unknownRef37="event:native:/OnPushIlistBtDeviceManager"
**unknownRef37="event:native:/OnPushIlistBtDeviceManager"
**<IItem name="iitem_address_setting" unknown1="0x0" textDefault="text:msg_ipaddress_setting" textError="text:msg_auto"></IItem>
**<IItem name="iitem_address_setting" unknown1="0x0" textDefault="text:msg_ipaddress_setting" textError="text:msg_auto"></IItem>
In the previous examples the ''MlistID'' is the owner of the attribute that specifyes the event... so ''MlistID'' needs to be removed to deduce the event name
Probably another unknown is ''OnFocusOut'' (because ''Out'' is the opposite state of ''In'', it seems ''Focus'' and ''Scroll'' are intended to have 2 states)
OnPush is used a lot instead of the pad directions, as example on some menues of xmb settings column, when moving right is taken as a push
onPanelCommand seems to be an special event that can replace some of the standard events (used as a ''Button'' attribute)
==animattribdef-ps3.ini==
This file defines the names of the animation attributes used in the XML descriptor at the root of the .rco
PS3 doesnt seems to use too much animations inside rco's (with a few exceptions like gameboot animation, and inside system_plugin.rco etc...)
Only 5 unknowns. It seems that unknownInt5, unknownInt6, unknown7 has been implemented with rco 2.0 format specifically for PS3 (not supported in PSP). The others for lock/unlock existed before in rco 1.0 format (supported in PSP)
[MoveTo]
unknownInt5 = int
unknownInt6 = int
unknown7 = unk
[Lock]
unknownInt0 = int
[Unlock]
unknownInt0 = int
==tagmap.ini==
This file defines the names of the tags used in the XML descriptor at the root of the .rco
Only 2 unknowns:
[Object]
ObjUnknown0xB
ObjUnknown0x1B
=Other descriptors, not in setting files (seem to be hardcoded)=
==unknownByte==
In the xml representation of the .rco structure... every image inside the imagetree uses an unknown attribute named '''unknownByte'''. Is an attribute related with the image format and is equal to 0 in most of the PS3 images (very rarelly used)
*After searching in ALL the images contained inside ALL .rco files from firmware 4.76... there is a total of 72 images using '''unknownByte="1"''' (and 3098 images using '''unknownByte="0"''' for a total of 3170 images inside .rco's)
**7 images inside [[eula_net_plugin]].rco
**34 images inside [[newstore_plugin]].rco
**29 images inside [[regcam_plugin]].rco
**2 images inside [[system_plugin]].rco
from [[system_plugin]].rco
{{Boxcode|content=<syntaxhighlight lang="xml">
<Image name="tex_optionmenu_bg" src=".\RCO 476 ofw\system_plugin\Images\tex_optionmenu_bg.gim" format="gim" compression="zlib" unknownByte="1" />
<Image name="tex_optionmenu_base" src=".\RCO 476 ofw\system_plugin\Images\tex_optionmenu_base.gim" format="gim" compression="zlib" unknownByte="1" />
</syntaxhighlight>}}
*The 2 .gim files found using '''unknownByte="1"''' has some things in common:
**The size of both .gim file is exactlly 452KB (463.232 bytes)
**The resolution of both images in pixels is 512x206
**The first 0x80 bytes of the header in both is exactlly the same (see example below)
unknownByte .gim header example
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000  2E 47 49 4D 31 2E 30 30 00 50 53 50 00 00 00 00  .GIM1.00.PSP....
00000010  00 02 00 00 00 07 11 70 00 00 00 10 00 00 00 10  .......p........
00000020  00 03 00 00 00 07 11 60 00 00 00 10 00 00 00 10  .......`........
00000030  00 04 00 00 00 07 11 50 00 07 11 50 00 00 00 10  .......P...P....
00000040  00 30 00 00 00 03 00 00 02 18 00 D8 00 20 00 10  .0.........Ø. ..
00000050  00 01 00 02 00 00 00 00 00 00 00 30 00 00 00 40  ...........0...@
00000060  00 07 11 40 00 00 00 00 00 01 00 01 00 03 00 01  ...@............
00000070  00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
==minFirmwareVer==
This is a very important unknown. See: [[Talk:Resource_Container_%28RCO%29]]
==UMDFlag==
This attribute was named UMDFlag unofficially because it was found used in the .rco files contained inside PSP UMD discs only
The name seems not accurate enought (because PS3 cant read UMD discs) so maybe is something more generic like "disc media", though never has been found a PS3 disc containing .rco's and the '''HYBRID_FLAG''' used in the bluray contents descriptor file [[PS3_DISC.SFB]] for "music bluray" and "photo bluray" are completlly speculative

Latest revision as of 01:28, 7 April 2018

rcomage innacuracies, mistakes, bugs, or unsupported rco specifications[edit source]

Rebuild verification[edit source]

There is an easy way to verify if the building methods used by rcomage are exactlly like the ones used officially by sony, it basically consists in rebuilding an official rco, the hashes of the original and rebuilt .rco should match exactlly... in other words, after the rebuild the .rco file should be exactlly like the original

  • Requirements for this to work
    • the files needs to be extracted in "raw" format (if using "rcomage gui" in the DUMP tab uncheck all the checkboxes for GIM, VAG, VSMX)... long story short this is to avoid mistakes with the conversors
    • the rco TOC (aka what rcomage names "header compression") needs to use the same compression method than the original (if using "rcomage gui" in the COMPILE tab choose the correct "header compression" from NONE, ZLIB, RLZ)
      • rcomage doesnt keeps a record of this "header compression", so the way to identify it is by opening the original .rco in a hexeditor and check the value stored at absolute offset 0xC. See Resource Container (RCO)

This method is specially usefull with the .rco files that doesnt have "header compression" because is easyer to find the differences in a hexeditor, oldest PS3 firmware .rco's (like the ones in firmware 1.02) are not compressed

official dummy language string pointers not managed by rcomage[edit source]

Found in xmb_plugin_normal.rco firmware 1.02 (and probably most others using language text strings, is just in this one is more obvious where the problem happens)

  • xmb_plugin_normal.rco firmware 1.02 original and rebuild at absolute offset 0x50, is indicating the language pointers table starts at absolute offset 0x7EC (position is the same in both, original and rebuild)
    • but the size (indicated at offset 0x54) in original is 0x90... and in rebuild 0x78 (after rebuild is smaller, rcomage has "lost" some bytes from it)

The table contains the pointers for every text string for every language, PS3 firmware 1.02 supports up to 10 languages, and every language contains 3 text strings... this makes a total of 30 pointers, every pointer is 4 bytes size, so the whole table of language text pointers should be 120 bytes length (0x78 in hex)... this is what rcomage does

But sony added 6 more pointers to the end of the table (of 4 bytes length each) all filled with zeroes... can be considered padding, but also can be considered "dummy pointers" because belongs to the table of pointers

Now... the question (and the reason why rcomage doesnt adds this pading) is.... why sony added that "dummy pointers" ?

illuminati event one, theory one (in the track)
-----------------------------------------------
<sandungas> just found an "innacuracy" of rcomage when rebuilding files
<sandungas> im not calling it a mistake because it doesnt breaks the format
<sandungas> is an (seems stupid) padding sony adds in the original files.... but rcomage doesnt
<sandungas> the point is maybe is not so stupid and is based on how the contents are mounted in the console ram, aligned to memory blocks and stuff like that
<sandungas> actually, maybe this is dependant of the console (ps3 or psp) because the different ram management, hmmmm
<zecoxao_> you need ZingaBurga
<sandungas> yep :/
<sandungas> and i remember him talking about this
<sandungas> someone asked him why the rebuilding was not perfect... and he mentioned some "weird" padding sony did but he could not understand why it happens
<sandungas> i think i know why :)
<sandungas> is a dirty trick, not efficient because adds additionally unneeded padding, but assures you the text pointers are aligned properlly without need to make complex calculations
<sandungas> something like this...
<sandungas> if total numer of languages inside .rco is not multiple of 4..... add "dummy" languages until it reaches a multiple of 4
  • It needs to be verifyed further in other .rco files but my theory is this: --Sandungas (talk) 00:56, 21 September 2016 (UTC)
    • the table of pointers needs to be aligned to 0x10 bytes boundary (from the start of the table itself), but trying to calculate the padding before building the file is a pita (because there can be lot of languages and lot of text strings for every language, is needed to read every text, multiply by language number, then calculate padding, etc... is not efficient)... so they decided to add this "blind alignment prevention". The thing consists in creating the table by cummulating "pointer placeholders" that contains ALWAYS groups of pointers that are a multiple of 4 based in the number of languages stored inside the .rco (this way the number of strings for every language doesnt matters at all, the table will always be aligned to 0x10 bytes)
    • As example, in the worst scenario posible... if the rco only contains one language, and only one text string for that language... at building time the table of pointers is created with a size of 0x10 bytes (to store 4 pointers for 4 languages minimal)... then the first pointer is filled... and because there are not more pointers to store the other areas are kept filled with zeroes
    • Another example, with 5 languages... the table is created for 8 languages (rounded to the next multiple of 4) so "pointer placeholders" are added to the table in groups of eight
      • In the first step the table has room for 8 pointers and is filed with the 5 pointers for the first text string... now is calculated how many "pointer placeholders" are left in the table = 3... so the table is increased in size with 8 "pointer placeholders" more... now the table has 11 available "pointer placeholders" and are filled with the 5 pointers for the second string stored in positions 6 up to 10... now is calculated how many "pointer placeholders" are left in the table = 1... so the table is increased in size with 8 "pointer placeholders" more... and so on
      • Note the number of strings doesnt matters (not needed to know, is not a variable in the function), the process is repeated in a loop and the table will always be aligned to 0x10 bytes boundary
  • In PS3 xmb_plugin_normal.rco from firmware 1.02 (with 10 languages) the "pointer placeholders" that are cummulated to make the table bigger (needs to be bigger than 10 and a multiple of 4) are added in groups of 12 pointers (chunks of 0x30 bytes). In the original file the table has a size of 0x90 bytes, this means the table has been increased in size 3 times in the .rco building process



  • There are other innacuracies when rebuilding this file... not sure if are related with text strings too though... are hard to see where is the problem because the areas are displaced by the problem explained above
    • as example... the last event in the "events table" in original is native:/Bar::onCursorMove (seems to be stored in a different order)

RCO format version 0x93 (used by PS3 firmware 082.006)[edit source]

There is a problem with the "Image" entries (located under "ImageTree") on the TOC. At the time sony "ported" the RCO format from PSP-to-PS3 it was added an additional value for "Image" (usually a 0x1 and his purpose is still unknown). This additional value was added at pre-retail DECR 085 series (rco_version 0x97). More info here: RCOXML_Images#Image

The firmwares affected are all PS3 pre-retail 082, 083, and 084 series

Fix for rcomage: if endianess = big and rco_version < 0x97 this value doesnt exists

RCO format version 0x55 (used by PSP firmware 0.6.5)[edit source]

PSP firmware 0.6.5 uses a primitive version of the rco format, this is an example of the rco header (first 0x94 bytes) of system_plugin.rco, most notable change is the header is smaller (so is missing some areas for features that was not implemented yet). I dont plan to look for all the changes but this little example hopefully will show what areas are missing to have an overall idea of the order of how features was implemented in the rco format. This version of the rco format is not compatible with rcomage... but it should by deleting the "unknowns" in the definitions of the source code (lines 51 and 76 of rcofile.h) then compile it (not tested, other errors can happen but this should work) the idea doesnt works, compiler returns other errors http://paste.ubuntu.com/23207840/

Original header (remember PSP uses little endian so some bytes are swapped)

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  00 50 52 46 55 00 00 00 00 00 00 00 00 00 00 00  .PRFU...........
00000010  94 00 00 00 FF FF FF FF 7C 0A 00 00 34 08 00 00  ”...ÿÿÿÿ|...4...
00000020  FF FF FF FF BC 00 00 00 FF FF FF FF 7C 0B 00 00  ÿÿÿÿ¼...ÿÿÿÿ|...
00000030  FF FF FF FF E0 0C 00 00 68 00 00 00 48 0D 00 00  ÿÿÿÿà...h...H...
00000040  9C 04 00 00 E4 11 00 00 04 00 00 00 F0 0B 00 00  œ...ä.......ð...
00000050  28 00 00 00 18 0C 00 00 94 00 00 00 FF FF FF FF  (.......”...ÿÿÿÿ
00000060  00 00 00 00 AC 0C 00 00 2C 00 00 00 D8 0C 00 00  ....¬...,...Ø...
00000070  08 00 00 00 FF FF FF FF 00 00 00 00 E8 11 00 00  ....ÿÿÿÿ....è...
00000080  40 DF 01 00 28 F1 01 00 F0 58 02 00 FF FF FF FF  @ß..(ñ..ðX..ÿÿÿÿ
00000090  00 00 00 00                                      ....
Areas Offset Length Example Name Notes
Header
0x00 0x04 PRF magic PRF in little endian
0x04 0x04 55 00 00 00 version 0x55 = one of the firmwares for PSP
0x08 0x04 00 00 00 00 unknown
0x0C 0x04 00 00 00 00 compress_header 0x00 = uncompressed
0x10 0x04 94 00 00 00 toc_maintree_absolute_offset MainTree at absolute offset 0x94
0x14 0x04 FF FF FF FF toc_scripttree_absolute_offset
0x18 0x04 7C 0A 00 00 toc_languagetree_absolute_offset TextTree at absolute offset 0xA7C
0x1C 0x04 34 08 00 00 toc_soundtree_absolute_offset SoundTree at absolute offset 0x834
0x20 0x04 FF FF FF FF toc_modeltree_absolute_offset
0x24 0x04 BC 00 00 00 toc_imagetree_absolute_offset ImageTree at absolute offset 0xBC
0x28 0x04 FF FF FF FF toc_unknowntree_absolute_offset or toc_fonttree_absolute_offset
0x2C 0x04 7C 0B 00 00 toc_objecttree_absolute_offset ObjectTree at absolute offset 0xB7C
0x30 0x04 FF FF FF FF toc_animationtree_absolute_offset
0x34 0x04 E0 0C 00 00 strings_texts_absolute_offset strings texts table at absolute offset 0xCE0
0x38 0x04 68 00 00 00 strings_texts_length strings texts table size 0x68
0x3C 0x04 48 0D 00 00 strings_labels_absolute_offset strings labels table at absolute offset 0xD48
0x40 0x04 9C 04 00 00 strings_labels_length strings labels size 0x49C
0x44 0x04 E4 11 00 00 strings_events_absolute_offset strings events table at absolute offset 0x11E4
0x48 0x04 04 00 00 00 strings_events_length strings events size 0x4
0x4C 0x04 F0 0B 00 00 text_pointer_table_offset
0x50 0x04 28 00 00 00 text_pointer_table_length
0x54 0x04 18 0C 00 00 image_pointer_table_offset
0x58 0x04 94 00 00 00 image_pointer_table_length
0x5C 0x04 FF FF FF FF model_pointer_table_offset
0x60 0x04 00 00 00 00 model_pointer_table_length
0x64 0x04 AC 0C 00 00 sound_pointer_table_offset
0x68 0x04 2C 00 00 00 sound_pointer_table_length
0x6C 0x04 D8 0C 00 00 object_pointer_table_offset
0x70 0x04 08 00 00 00 object_pointer_table_length
0x74 0x04 FF FF FF FF anim_pointer_table_offset
0x78 0x04 00 00 00 00 anim_pointer_table_length
0x7C 0x04 E8 11 00 00 image_data_section_offset
0x80 0x04 40 DF 01 00 image_data_section_length
0x84 0x04 28 F1 01 00 sound_data_section_offset
0x88 0x04 F0 58 02 00 sound_data_section_length
0x8C 0x04 FF FF FF FF model_data_section_offset
0x90 0x04 00 00 00 00 model_data_section_length
12 bytes of unknowns 0xFF's was added here for newer versions of the rco format

Missing descriptors in rcomage current version (1.1.1)[edit source]

miscmap.ini[edit source]

  • See Languages
    • unknown0x10.xml is Polish
    • unknown0x11.xml is Portuguese (Brazil)
    • unknown0x12.xml is English (Great Britain)
    • unknown0x13.xml is Turkish
  • The languages are listed in the file miscmap.ini... you can add the unknowns by yourself to the languages table, example:
[languages]
00_Japanese       ; ja
01_English_US     ; en
02_French         ; fr
03_Spanish        ; es
04_German         ; de
05_Italian        ; it
06_Dutch          ; nl
07_Portuguese_PT  ; pt
08_Russian        ; ru
09_Korean         ; ko
10_Chinese_T      ; ch
11_Chinese_S      ; zh
12_Finnish        ; fi
13_Swedish        ; sv
14_Danish         ; da
15_Norwegian      ; no
16_Polish         ; pl
17_Portuguese_BR  ; br
18_English_GB     ; gb
19_Turkish        ; tr
  • changes
    • Added the 4 unknown languages (Polish, Portuguese_BR, English_GB, Turkish)
    • Added "two-digit" language code before name, and language variant after name
    • Changed names for variants of English_US/GB, Portuguese_PT/BR, and Chinese_T/S
    • Changed commented languages to "two-letter" language code, from explore_plugin.sprx
    • Fixed "Portugese" typo

tagmap.ini[edit source]

This file defines the names of the tags used in the XML descriptor at the root of the .rco

Only 2 unknowns:

[Object]
ObjUnknown0xB
ObjUnknown0x1B

animattribdef-ps3.ini[edit source]

This file defines the names of the animation attributes used in the XML descriptor at the root of the .rco

Only 5 unknowns. It seems that unknownInt5, unknownInt6, unknown7 has been implemented with rco 2.0 format specifically for PS3 (not supported in PSP). The others for lock/unlock existed before in rco 1.0 format (supported in PSP)

[MoveTo]
unknownInt5 = int
unknownInt6 = int
unknown7 = unk

[Lock]
unknownInt0 = int

[Unlock]
unknownInt0 = int

objattribdef-ps3.ini[edit source]

This file defines the names of the object attributes used in the XML descriptor at the root of the .rco

onInit, onPush, buttonPush, btnClick, onButton, onLoad... sometimes are used as a generic "run" command and can replace any of the other events (as example on some menues of xmb settings column when moving right is taken as a push) so is hard to identify the official name that are replacing. For this reason the list here keeps some counters of how many times have been found in official firmware. The counters works as a justification of why some names has been changed based in the number of times used

onPanelCommand seems to be an special event that can replace some of the standard events (used as a Button attribute)

Standard object attributes[edit source]

; -- BEGIN STANDARD POSITION DEFINITION --
onLoad           onInit <---------- used 5485 times in 4.76 firmware, most with "OnInit" or "nothing"
; -- END STANDARD POSITION DEFINITION --

Specific object attributes[edit source]

[Page]
onInit        <------------- used 625 times in firmware 4.76. Around 607 onInit, 18 onOpen
onContextMenu onContext <--- better to use a more generic name because "onContext" is used in several other objects and is technically the same event for all them

[Button]
image2         focus
unknownRef29   text
unknownEvent31 onPush   <---- used 292 times in firmware 4.76. Around 258 onPush, 24 buttonPush, 5 btnClick, 3 onButton, 2 onCancel
unknownEvent33 onFocusIn
unknownEvent35 onFocusOut
unknownEvent37 onFocusLeft
unknownEvent39 onFocusRight
unknownEvent41 onFocusUp
unknownEvent43 onFocusDown
unknownEvent45 onContext

[XMenu]
onEnter        onPush <---- used 2 times in firmware 4.76. Both onPush
unknownEvent28 onCursorMove
onLabelLoad    onScrollIn <---- official name
unknownRef32   onScrollOut

[XMList]
unknownRef3    text

[XList]
onMove        onCursorMove <---- official name (is the same, but this way matches with the others)

[Progress]
unknownRef25   image
unknownRef27   image2 <------ shadow image ?

[MList]
unknownRef33 onPush
unknownRef35 onCursorMove
unknownRef37 onFocusIn
unknownRef39 onFocusOut
unknownRef41 onFocusLeft
unknownRef43 onFocusRight
unknownRef45 onFocusUp
unknownRef47 onFocusDown
unknownRef49 onScrollIn
unknownRef51 onScrollOut

[MItem]
unknownRef4  altText2

[Spin]
unknownEvent29  onDecide
unknownEvent31  onCancel
unknownEvent33  onRollIn

[Action]
unknownRef0     text

[ItemSpin]
unknownEvent33  onDecide
unknownEvent35  onCancel
unknownRef41    onFocusIn
unknownRef43    onFocusOut
unknownRef45    onFocusLeft
unknownRef47    onFocusRight

[LList]
unknownEvent40  OnScrollIn

[Edit]
unknownEvent31  onDecide
unknownRef33    onCancel
unknownEvent39  onFocusLeft
unknownEvent41  onFocusRight
unknownObject43 object1
unknownObject45 object2

[Clock]
unknownText25   text
unknownText27   altText
unknownEvent33  onDecide
unknownEvent35  onCancel
unknownEvent41  onFocusLeft
unknownEvent43  onFocusRight
unknownEvent49  onTickClock 

[IList]
unknownEvent29  onFocusLeft
unknownRef31    onFocusRight
unknownRef35    onFocusDown
unknownRef37    onPush <------------ found used this way (and only 1 time in firmware 4.76), but it seems OnPush is used here as a generic event

[IItem]
textDefault    text
textError      altText  <---- because is not an error strictlly

[UButton]
onLeft         onFocusLeft  <----- official name
onRight        onFocusRight  <---- official name
onUp           onFocusUp  <------- official name
onDown         onFocusDown  <----- official name

[CheckboxGroup]
unknownRef33    onPush      <---- used 23 times in 4.76 firmware, 17 onPush, the others "nothing"
unknownRef35    onCursorMove
unknownRef37    onFocusIn
unknownRef39    onFocusOut
unknownRef41    onFocusLeft
unknownRef43    onFocusRight
unknownRef45    onFocusUp
unknownRef47    onFocusDown
unknownRef49    onScrollIn

[CheckboxItem]
unknownRef1     text

[EditBox]
unknownRef59   image
unknownRef61   image2
unknownRef63   onPush      <---- used 74 times in 4.76 firmware, 62 onPush, 1 onBtnClick, 11 "nothing"
unknownRef65   onFocusIn
unknownRef67   onFocusOut
unknownRef69   onFocusLeft
unknownRef71   onFocusRight
unknownRef73   onFocusUp
unknownRef75   onFocusDown
  • Examples:
    • onInit="event:native:/OnListPageOpen"
    • onInit="event:native:/OnContentsSelectPageOpen"
    • onInit="event:native:/OnModeSelectPageOpen"
    • onInit="event:native:/onInit_page_Wizard"
    • unknownRef3="text:msg_game"
    • unknownRef33="event:native:/OnPushMlistID"
    • unknownRef33="event:native:/Menu::cbPush"
    • unknownRef37="event:native:/OnFocusInMlistID"
    • unknownRef41="event:native:/Menu::cbFocusLeft"
    • unknownRef47="event:native:/Menu::cbFocusDown"
    • unknownRef49="event:native:/OnScrollInMlistID"
    • unknownRef49="event:native:/Menu::cbScrollIn"
    • unknownRef51="event:native:/Menu::cbScrollOut"
    • onLoad="event:native:/Bar::onInit"
    • onLoad="event:native:/onInit_ilist_NetworkInfomationList"
    • onEnter="event:native:/Bar::onPush"
    • unknownEvent28="event:native:/Bar::onCursorMove"
    • onLabelLoad="event:native:/Bar::onScrollIn"
    • unknownRef32="event:native:/Bar::onScrollOut"
    • image="image:tex_button" shadow="image:tex_button_shadow" image2="image:tex_button_focus" unknownRef29="text:msg_ok"
    • unknownEvent31="event:native:/XaiController::onPanelCommand"
    • unknownEvent37="event:native:/XaiController::onPanelCommand"
    • unknownEvent39="event:native:/XaiController::onPanelCommand"
    • shadowX="4" shadowY="-5" shadowPerspective="0" shadowRed="0.25" shadowGreen="0.25" shadowBlue="0.25" shadowAlpha="1" unknown48="0x0" unknown49="0x0" unknown50="0x0" unknownFloat51="1" unknownFloat52="1" unknownFloat53="1" unknownFloat54="1"
    • unknownRef63="event:native:/onPush_button_NetworkDhcpHostSetting"
    • unknownRef69="event:native:/onFocusLeft_button_NetworkAccounSetting" unknownRef71="event:native:/onFocusRight_button_NetworkAccounSetting" unknownRef73="event:native:/onFocusUp_button_NetworkAccounSettingPassword"
    • unknownRef75="event:native:/onFocusDown_button_NetworkAccounSettingUserId"
    • unknownEvent31="event:native:/onDecide_ipaddr_NetworkAddressSetIpaddress"
    • unknownRef33="event:native:/onCancel_ipaddr_NetworkAddrSetting"
    • unknownEvent31="event:native:/onDecide_ipaddr_NetworkAddressSetNetmask"
    • unknownRef33="event:native:/onCancel_ipaddr_NetworkAddrSetting"
    • unknownEvent39="event:native:/onFocusLeft_ipaddr_NetworkAddrSetting"
    • unknownEvent41="event:native:/onFocusRight_ipaddr_NetworkAddrSetting"
    • unknownObject43="object2:ipaddr_network_address_setting_ipaddress"
    • unknownObject45="object2:ipaddr_network_address_setting_defaultrooter"
    • unknownRef29="text:msg_agree"
    • unknownEvent31="event:native:/cbPush"
    • unknownEvent37="event:native:/cbFocusLeft" unknownEvent39="event:native:/cbFocusRight" unknownEvent41="event:native:/cbFocusUp" unknownEvent43="event:native:/cbFocusDown"
    • unknownEvent31="event:native:/OnControlPanelButtonPush" unknownEvent33="event:native:/OnControlPanelButtonFocusIn" unknownEvent35="event:native:/OnControlPanelButtonFocusOut" unknownEvent37="event:native:/OnControlPanelButtonFocusLeft" unknownEvent39="event:native:/OnControlPanelButtonFocusRight" unknownEvent41="event:native:/OnControlPanelButtonFocusUp" unknownEvent43="event:native:/OnControlPanelButtonFocusDown"
    • unknownRef33="event:native:/ctl_list_cbPush" unknownRef35="nothing" unknownRef37="nothing" unknownRef39="nothing" unknownRef41="nothing" unknownRef43="event:native:/ctl_list_cbFocusRight" unknownRef45="event:native:/ctl_list_cbFocusUp" unknownRef47="nothing" unknownRef49="event:native:/ctl_list_cbScrollIn" unknownRef51="event:native:/ctl_list_cbScrollOut"
    • unknownRef59="image:avc2_main_back_paper" unknownRef61="image:avc2_main_back_paper" unknownRef63="event:native:/cbPush"
    • unknownRef33="event:native:/Menu::cbPush" unknownRef35="event:native:/Menu::cbCursorMove" unknownRef37="nothing" unknownRef39="event:native:/Menu::cbFocusOut"
    • unknownEvent43="event:native:/VideoEditorUpload::ServiceSelect::OnFocusDownButton1" unknownEvent45="event:native:/VideoEditorUpload::ServiceSelect::OnContextMenuButton1"
    • unknownRef63="event:native:/OnCreatePageEditBtnClick" unknownRef65="event:native:/OnCreatePageEditBtnFocusIn"
    • unknownRef65="event:native:/DialogController::onEditBottonFocusIn" unknownRef67="event:native:/DialogController::onEditBottonFocusOut"
    • unknownEvent29="event:native:/OnDecideISpinDeviceConfigCameraSetting" unknownEvent31="event:native:/OnCancelISpinDeviceConfigCameraSetting" unknownEvent33="event:native:/OnRollInISpinDeviceConfigCameraSetting"
    • unknownRef33="event:native:/OnPushClistRegPSVitaConfig" unknownRef35="nothing" unknownRef37="event:native:/OnFocusInClistRegPSVitaConfig" unknownRef39="event:native:/OnFocusOutClistRegPSVitaConfig" unknownRef41="nothing" unknownRef43="nothing" unknownRef45="nothing" unknownRef47="event:native:/OnFocusDownClistRegPSVitaConfig" unknownRef49="event:native:/OnScrollInClistRegPSVitaConfig"
    • unknownRef33="event:native:/OnPushCheckBoxList" unknownRef35="event:native:/OnCursorMoveCheckBoxList" unknownRef37="nothing" unknownRef39="nothing" unknownRef41="nothing" unknownRef43="nothing" unknownRef45="event:native:/OnFocusUpCheckBoxList" unknownRef47="event:native:/OnFocusDownCheckBoxList"
    • unknownRef41="event:native:/OnFocusLeftClistAudioOutputConfig" unknownRef43="event:native:/OnFocusRightClistAudioOutputConfig"
    • unknownEvent33="event:native:/OnTitleJumpSpinDecide" unknownEvent35="event:native:/OnTitleJumpSpinCancel" unknownRef37="nothing" unknownRef39="nothing" unknownRef41="event:native:/OnTitleJumpButtonFocusIn" unknownRef43="event:native:/OnTitleJumpButtonFocusOut"
    • unknownRef45="event:native:/OnFocusLeftNumSpinWizardEventHandler" unknownRef47="event:native:/OnFocusRightNumSpinWizardEventHandler"
    • unknownEvent29="event:native:/EulaLicensingWizard::onFocusLeft" unknownRef31="event:native:/EulaLicensingWizard::onFocusRight"
    • unknownRef35="event:native:/ConsoleAutoPowerOffPage::OnFocusDownIlist"
    • unknownEvent33="event:native:/OnDecideClockFirstConfig" unknownEvent35="event:native:/OnCancelClockFirstConfig" unknownRef37="nothing" unknownRef39="nothing" unknownEvent41="event:native:/OnFocusLeftFirstConfig" unknownEvent43="event:native:/OnFocusRightFirstConfig" unknownRef45="nothing" unknownRef47="nothing" unknownEvent49="event:native:/OnTickClockFirstConfig"
    • <Action name="item_audio_device_config_volume_off" unknownRef0="text:msg_off"></Action>
    • unknownRef1="text:msg_update_auto_off_ps3_after_update"
    • unknownRef3="text:msg_game"
    • unknownRef25="image:tex_progress_bar" unknownRef27="image:tex_progress_bar_in"
    • <MItem name="item_network_accesspoint_list" text="text:msg_none" altText="text:msg_none" unknownRef4="text:msg_none"></MItem>
    • unknownEvent40="event:native:/OnScrollInListEdyViewer"
    • unknownText25="text:msg_am" unknownText27="text:msg_pm"
    • unknownRef37="event:native:/OnPushIlistBtDeviceManager"
    • <IItem name="iitem_address_setting" unknown1="0x0" textDefault="text:msg_ipaddress_setting" textError="text:msg_auto"></IItem>