Editing Talk:RCOXML Objects
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
= | =Objects not used in PS3 official firmware= | ||
Some of them maybe supported | |||
[ObjUnknown0xB] | |||
[XItem] | |||
[ModelObject] | |||
[LItem] | |||
[Icon] | |||
[UButton] | |||
[ObjUnknown0x1B] | |||
=Float conversions= | |||
Some of the values in the tables in frontpage (in the red marked rows as speculative) was dumped by rcomage as type "unk" but are "floats", for this reason rcomage didnt made the float-to-decimal conversion and appears as a hexidecimal value with the endianess swapped (bytes reversed) and the starting zeroes removed | |||
To make the decimal conversion you can use this web http://www.h-schmidt.net/FloatConverter/IEEE754.html | |||
Example, a value '''0xa0c0''' was extracted by using the type "unk". After changing endianess manually the value is '''0xc0a00000'''. And after the decimal conversion the result is '''-5''' | |||
=Standard object attributes= | |||
Are used 5485 times in 4.76 PS3 firmware, most objects uses them so is the most important group of attributes and are critical to fully understand how all the other objects works. Also the way that is stored some of the "unknown" attribute values is the same used in other unknowns from other objects. in few words, by identifying this unknowns there will be a lot of other objects affected not only in the "standard attributes" but also in the "specific attributes" | |||
* | *Are pointers to the grid tables !!!, see [[XMB Layouts]]. The firmware loads the rco, calculates the pointer to a line of the grid table, and loads the value from the grid table | ||
** | *The value in the rco is composed by: "grid line reference" (first 4 bytes byteswapped, then converted to decimal) + "unknown flags?" (last 4 bytes byteswapped). The unknown maybe is related with the presence (or not) of a alternative value in the factor tables | ||
* | *The grid is a 3D scene defined by the X, Y, Z axis, the camera (TV screen frame) is located in the vertical of Z axis, the world coordinates is located in the center of the screen (0, 0, 0) | ||
** | *In the proposed names below, the "group1" and "group2" are just temporal names because is partially unknown what represents (one of them is position, the other is not clear) | ||
** | *rcomage is not able to extract the 2 values that composes each attribute separatedlly, for this reason the better way to manage this data types is as "unk" (for a raw value extraction) | ||
**standardUnknown17 should be renamed to something like...... gridRefgroup1X | |||
**standardUnknown18 should be renamed to something like...... gridRefgroup1Y | |||
**standardUnknown19 should be renamed to something like...... gridRefgroup1Z | |||
**standardUnknownInt20 should be renamed to something like... gridRefgroup2X | |||
**standardUnknownInt21 should be renamed to something like... gridRefgroup2Y | |||
**standardUnknown22 should be renamed to something like...... gridRefgroup2Z | |||
{{RCOXML_standard_object_attributes}} | |||
==Unknown17, Unknown18, Unknown19== | |||
The 3 are related, and stores the value in the same format (this format is also used by a lot of specific attributes of other unknowns), some examples: | |||
== | standardUnknown17="0xf6010100" standardUnknown18="0xf7010100" standardUnknown19="0xf8010100" | ||
standardUnknown17="0xf9010100" standardUnknown18="0xfa010100" standardUnknown19="0xfb010100" | |||
standardUnknown17="0x80040100" standardUnknown18="0x81040100" standardUnknown19="0x82040100" | |||
standardUnknown17="0x84040100" standardUnknown18="0x85040100" standardUnknown19="0x86040100" | |||
standardUnknown17="0x120f0100" standardUnknown18="0x140f0100" standardUnknown19="0x6000100" | |||
standardUnknown17="0xfc0e0000" standardUnknown18="0xfe0e0000" standardUnknown19="0x6000000" | |||
standardUnknown17="0x4000100" standardUnknown18="0x5000100" standardUnknown19="0x6000100" | |||
Is not very usuall to see the 3 used consecutivelly (most times the first or the last stores a 0x0000, 0x0001, 0x0100, or 0x0101), but are used this way several times inside firmware, and its values uses to increases in + 0x1000000 or + 0x2000000 | |||
==UnknownInt20, UnknownInt21, Unknown22== | |||
Seems related too, <strike>but uses a different value format</strike>, some examples: | |||
Attribute 20 and 21 of the examples below are not valid because was extracted as "int" !!! | |||
standardUnknownInt20="0x1029a" standardUnknownInt21="0x1029b" standardUnknown22="0x100" | |||
standardUnknownInt20="0x10cfa" standardUnknownInt21="0x10cfb" standardUnknown22="0x100" | |||
standardUnknownInt20="0x10f38" standardUnknownInt21="0x10f39" standardUnknown22="0x100" | |||
standardUnknownInt20="0x10b75" standardUnknownInt21="0x10b76" standardUnknown22="0x100" | |||
standardUnknownInt20="0x10675" standardUnknownInt21="0x10676" standardUnknown22="0x100" | |||
standardUnknownInt20="0x10679" standardUnknownInt21="0x1067a" standardUnknown22="0x100" | |||
standardUnknownInt20="0x10683" standardUnknownInt21="0x10684" standardUnknown22="0x100" | |||
standardUnknownInt20="0x1067f" standardUnknownInt21="0x10680" standardUnknown22="0x100" | |||
standardUnknownInt20="0x1068b" standardUnknownInt21="0x1068c" standardUnknown22="0x100" | |||
standardUnknownInt20="0x10687" standardUnknownInt21="0x10688" standardUnknown22="0x100" | |||
standardUnknownInt20="0x1068b" standardUnknownInt21="0x1068c" standardUnknown22="0x100" | |||
standardUnknownInt20="0x10007" standardUnknownInt21="0x10008" standardUnknown22="0x100" | |||
standardUnknownInt20="0x10d94" standardUnknownInt21="0x10d95" standardUnknown22="0x100" | |||
standardUnknownInt20="0x10d94" standardUnknownInt21="0x10d96" standardUnknown22="0x100" | |||
standardUnknownInt20="0x10d9b" standardUnknownInt21="0x10d9c" standardUnknown22="0x100" | |||
standardUnknownInt20="0x10d7d" standardUnknownInt21="0x10d7e" standardUnknown22="0x100" | |||
standardUnknownInt20="0xef8" standardUnknownInt21="0xef9" standardUnknown22="0x840d0000" | |||
*standardUnknown22 (used 5485 times) with value: | |||
**"0x0" (5411 times) | |||
**"0x100" (73 times) | |||
**"0x840d0000" (1 time, inside hknw_plugin.rco) | |||
Example from hknw_plugin.rco | |||
{{Boxcode|content=<syntaxhighlight lang="xml"> | |||
<Plane name="hknw_menu_help1_LR" standardPosX="0" standardPosY="0" standardPosZ="0" standardRedScale="1" standardGreenScale="1" standardBlueScale="1" standardAlphaScale="1" standardWidth="0" standardWeight="0" standardDepth="0" standardScaleWidth="1" standardScaleHeight="1" standardScaleDepth="1" standardIconOffset="0x0" standardOnInit="nothing" standardUnknown17="0xf60e0000" standardUnknown18="0xf70e0000" standardUnknown19="0x6000000" standardUnknownInt20="0xef8" standardUnknownInt21="0xef9" standardUnknown22="0x840d0000" planeImage="image:tex_Arrow_LR1" planeDisplayMode="0x0"></Plane> | |||
</syntaxhighlight>}} | |||
---- | |||
The value format seems the same in all the 6 unknowns, because the 0x840d0000 is storing bytes in the order: xx0yzzzz (this pattern matches with lot of other unknown attributes, standard and specific) | |||
The zero is a real zero and uses to appear in that position (not always but very common) because the first 2 bytes needs to be swapped like this: 0yxx | |||
The zzzz seems separated, and usually stores only a 0x0000, 0x0001, 0x0100, or 0x0101 | |||
The | |||