CXML decompiler (
https://bitbucket.org/SilicaAndPina/cxml-decompiler) gives incorrect output for many of the numbers, including integers, floats, and style IDs. Integers and floats are fucked for reasons unknown. Style IDs, correctly called hashes (see below), have the wrong endian and also the wrong offset.
Contary to the name and as stated on
https://playstationdev.wiki/psvitadevwiki/index.php?title=Resource_Container_CXML_(RCO,_QRC,_Theme_Files,_RAF,_CXML) hashes are not just for styletable.
I wasn't about to setup a build environment for C# so I found an older program
https://github.com/angguss/rco-dump written in C++. rco-dump at least gives the correct integers and floats, and have the correct endian for hashes (on a little endian host), but the hash offsets are still wrong. Either Silica copy pasted from this program, or they both copy pasted from a common source, which incidentally resulted in the hashes having the wrong endian in CXML decompiler.
There is another benefit of rco-dump which is that the localised string files are recursively created at the same time, but it will not convert GIMs and VAGs like CXML decompiler.
The fix is simple, hash offsets are element offsets rather than byte offsets, so the offsets have to multiplied by 4. See
https://github.com/angguss/rco-dump/pull/3. It has some problems with constructing output pathes. Place the RCO file in the same directory when invoking the program, otherwise it will segfault.
These are the correct names for the CXML tables. (from PSM sdk cxml.py)
attr_type_int = 1 # 32bit整数
attr_type_float = 2 # 32bit浮動小数
attr_type_string = 3 # 文字列
attr_type_wstring = 4 # ワイド文字列
attr_type_hash = 5 # ハッシュ
attr_type_intarray = 6 # 32bit整数配列
attr_type_floatarray = 7 # 32bit浮動小数配列
attr_type_filename = 8 # ファイル
attr_type_id = 9 # ID
attr_type_idref = 10 # IDへの参照
attr_type_idhash = 11 # IDハッシュ
attr_type_idhashref = 12 # IDハッシュへの参照
