Talk:RCOXML Objects

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"

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"

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, but uses a different value format, some examples:

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

Code Sample

---

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