There's still so much to investigate & potentially use in all these rco/prx implementations.
Also given their importance & usefulness, all the reversed system plugins have been documented on the wiki but it would require some polishing, completing the missing info, detailing a lot of parameters that are still sketchy... And maybe a few more snippets to illustrate. Ideally...
Don't get me wrong it is not a criticism of my beloved wiki lol. Just hoping it could be get improved...
90% of wiki is still a "work in progress", everybody is invited to edit it, i want to point to a common problem all wiki editors probably had
Personally, i always wanted to start adding info in wiki about RCO and other files directlly related to it, also as a preservation from all the mods from PSP scene, i had this in mind like years ago, but i realized soon that to make this in a good way first was needed to create an "skelleton" of pages related to separate the info by groups (also, inside every one of the pages anothoer Skelleton" of sections)
The adventure to create all that is something that scared me for long time (years), not just about completing them (that is a goal i know i cant do) but just to imagine how to perpare new pages to start adding info in them is an oddisey by itself because for that you need to have an small overall idea of how all works
This is why lot of pages related to RCO are like half written and dirty, the good thing is are ready and prepared to continue growing
Time ago there was nothing in wiki related to RCO
With mysis and the modules/plugins/vsh happened the same, at some point we had several discussion with eussNL too thinking wich was the best way to do it, and eussNL decided to create new sections, pages for every plugin, etc... this was one of the massive expansions wiki had (like with RCO and some others i did related with XMB)
This is why the plugin pages are also a bit empty, are mostlly worklogs
There are not explains in each plugin page about what the plugin does (for newcomers, wiki is for everyone, not just coders, things needs to be explained in plain words at top as an introduction to the page), ias not explained what is exactlly an "interface", etc...
That kind of things usually are added by wiki editors when doing a rewrite of the page, or when trying to improving it for completion purposes... but this doesnt uses to happen until the page (or a section of that page) is about to be completed
@sandungas I was looking at some xmls the other day and I noticed that the bar_action is present in some XMLs without lbl_half and it uses parameters. For example the
category_sysconf.xml - there are few, but:
<Table key="pd_voice_changer">
<Pair key="icon_rsc"><String>tex_sett</String></Pair>
<Pair key="title_rsc"><String>msg_voice_changer</String></Pair>
<Pair key="info_rsc"><String>msg_voice_changer_explanation</String></Pair>
<Pair key="bar_action"><String>voice_changer</String></Pair>
</Table>
I took a look at the decompiled sysconf_plugin.rco but there are no references to "voice_changer" in it Both "msg_voice_changer/explanation" strings are present in the .prx, but the bar_action string is not.
I noticed the values of bar_action inside sysconf_plugin, i use to add all valid values i find in this table, just as an start point to know wich kind of values are used officially and should be cosidered valid for tests
http://www.psdevwiki.com/ps3/XMBML_Coding#Attributes_.28Pairs.29
That table is also another thing that went out of control in wiki, i could never imagine it was going to reach that size when i started, but is the only place where are documented all that pair keys
The problem... there is no room in the table to explain how works each key... the explains are at bottom of the table but sucks a bit, i guess this is other of the wiki things that needs to be "expanded" to a new page
I cant tell much about bar_action, all i said about it was speculation, iirc the only place when uses values (other than the value "none") is in sysconf_plugin
And sysconf_plugin is pretty special, it does some things that the other XMB columns cant do (like the autohiding and autodisplaying of groups of icons when you press a secret button combo), also is very restrictive, it looks like the .sprx overrides the changes made in other files
Related with what you was asking...
From a sprx you can load "rcoxml objects" selectivelly by its label, usually the "Page" objects that has unique names to identify them (the pages doesnt displays anything btw, dont think in them as something visual, just as the root of a group of children objects)
But doesnt matches with the value you was looking for (the voice_changer in your example)
So dont know... maybe there is a link in between we are missing (some place where the label names are replaced by others)
Is also posible that the "bar" is refered to that two bars i mentioned (progress and scroll) in a generic way, not a direct reference to the rco by its label
Most of this brainstorming is based in the fact that a "bar" (from bar_action) and "half" (from lbl_half) looks like something visual, and all visual stuff is directlly or indirectlly connected to RCO
And for an RCO there are just that 2 bars (progress or scroll)
Also, lets say that happens like with the module-name and module_action that are used consecutivelly... first you specify the name of the module, and them an extended characteristique for it
In the same way bar_action and lbl_half could be... first you specify the action, and then the kind of action (half bar)
More brainstorming... lets say a bar by default has 100 "steps" to fill it completlly... by using "half" then the bar has the same lenght but it fills faster (because only has half of the steps)
Lol... i know this was too much, but anyway, just thinking loud, i never took a look at this very seriouslly and never made any test with it
------------
But actually... while writing this has coming a new idea that i really like
As said... with module_name and module_action first you specify the name and then the action (in the opposite order should not work btw, the order is important)
And we know that exists bar_action so....
bar_name ---> bar_action
In other words, im saying that bar_name exists (this has never been found along hundreds of rco files i been performing searchs from pre-retail up to latest PSP and PS3 firmwares)
Speculation 100% but after writing all this i think there are big probabilities for this to be true
