Endless Paradigm

Found a new unknown,. :) >>UnknownInt18 when set to 0xffff the size settingsand position settings are disabled,. prob all settings in the line,.
If set to 0x10000 all settings work,.
example

Vegetano1 Wrote: [ -> ]Found a new unknown,. :) >>UnknownInt18 when set to 0xffff the size settingsand position settings are disabled,. prob all settings in the line,.
If set to 0x10000 all settings work,.
example

XML Code

<Plane name="music_plane_menu" posX="330" posY="118" posZ="0" redScale="1" greenScale="1" blueScale="1" alphaScale="0" width="240" height="48" depth="0" scaleWidth="1" scaleHeight="1" scaleDepth="1" iconOffset="0x0" onInit="nothing" image="nothing" unknownInt18="0xffff"> <Plane name="music_plane_back" posX="0" posY="0" posZ="0" redScale="1" greenScale="1" blueScale="1" alphaScale="1" width="240" height="48" depth="0" scaleWidth="1" scaleHeight="1" scaleDepth="1" iconOffset="0x0" onInit="nothing" image="image:music_tex_panel_back" unknownInt18="0x10000"></Plane>

---

Yes, it is display mode.

0x0 stretch
0xFFFF center
0x10000 local level stretch
0x20000 local vertical stretch
0x30000 local stretch

Some unknow value i modify rcomage's ini and take it in ctftool, You can use CTFtoolMenu dump rco to check it.

Thanks for the info patpat.

are the new found unknown values included in 1.1.1?

The latest INIs aren't included in v1.1.1, but should be here: http://endlessparadigm.com/forum/showthr...#pid326926

You can always grab my latest versions from here: https://github.com/zingaburga/RCOMage/tree/master/data

i found something for you to crunch on :)

xmb_plugin_normal.rco from 3.55 firmware on ps3 fails if you unpack it and repack it unmodified no matter what settings you use.
this one contains the settings for the clock, PSN category icon and various other stuff.
repacking it with rcomage always makes the psn icon vanish, corrupts the background of the clock (it turns into a white brick O.O) and propably causes something else i haven't found yet.

tested with writing directly to dev_flash on 3.55-kmeaw.

Did you perform GIM » PNG conversions when you dumped?  If so, can you try with no conversions whatsoever?

I'm getting pretty much byte identical output, with the exception of some events which are placed slightly differently (shouldn't affect the file though).

I originally tested by converting gims but it seems to work when i don't do that, so the problem would be the gim's then
are there any other ways to do gim's instead of gimconv you used on RCOmage ?

edit: alos, i might have found an unknown here, but needs more testing.

Quote:<Text name="clock" posX="0" posY="-12" posZ="0"  ...... unknown55="0xffffffff" unknownInt56="0x13" unknownInt57="0x3" unknown58="0x0"></Text>

i thought that unknown55 looks like a color and the clock text color is indeed #FFFFFF
changing the last 2 F's (alpha) to 00 makes the clock vanish (alpha = 0) so it's invisible, but changing the color itself didn't work as of yet.
needs more testing.

Hmm, interesting, it appears that some of the GIMs in there are using DXT5 colour format, which is somewhat non-standard, which might explain why they won't work when converted to PNG then back to GIM.

The following images in xmb_plugin_normal.rco use DXT5 colour:

• tex_indi_chat
  
• tex_indi_message
  
• tex_indi_online
  
• tex_indi_online

If you don't need to edit them, you can dump without converting and manually convert the remaining three images (or do 2 dumps and fix up the XML).

If you want to edit those images though, you can try manually converting them to GIM, forcing Gimconv to use DXT5 colour, using a command line like:

for each image.  Then reference these GIM files in the XML so Rcomage can merge it.

Hope that helps.

thanks, I'll try it and see what happens.

however, i noticed that atleast tex_psn.gim and tex_indi_bg.gim corrupt every time (these are most noticeable as they show up in xmb all the time as opposed to the rest) , and assuming they're standard gims, it should then work.
do the other images mess these up or is there something else to this im missing?

either way, I'll try only converting tex_psn and see if it breaks

Edit: well that's a no-go. the tex_psn.gim breaks if converted normally or with DXT5 option.
gimconv also spat an error: illegal image order when converting back to gim, but since it compiled fine i just ignored that.
the DXT5 image was a lot smaller than the original too..

*back to drawing board*

edit2: i unpacked a pile of rco's and so far they all repeat the same. no graphics load on the console after being converted to png and back, modified or not.
tried with DXT5 too and also tried the -ps3 switch on gimconv. both compressed and uncompressed state (huge uncompressed rco files are an issue with the limited space on the flash too)

i wonder if there's something the ps3 does to check the files or something.. I fail to believe that all the gim's are somehow broken, and they do work with p3t theme files anyway...

im calling it a day for now as im totally empty on ideas.
Has anyone gotten modified graphics to load in ANY way aside with p3t themes ?

one last edit though....

i noticed that when gims are unpacked from rco without conversion, the header is something like "GIM1.00.PSP" ... now.. when a gim is packed from png with default settings (using rcomage's gui) the header becomes "MIG.00.1PSP" ..and when a gim is packed from png using -ps3 switch, the header becomes ".GIM1.00."

now... what settings do i use to get "GIM1.00.PSP" header back into it ?