Everytime I use this it crashes the icons on the xmb with no changes to the RCO.
i have the same problem i noticed that the files got larger and found the reason to be when it compiles the dumped files are not converted back from PNG to GIM if you don't convert the files when you dump the file still works.
Give me some space here, it's just a theory but that message is stating after a game/app exit, no other command requests were in the queue or have been made.
For example: When you are playing a game, and go back to the XMB and try to start another game, and hit Yes, it will exit the original game, put the NEW game into the queue, and that would be your "Request event"
Also in theory: we can probably do something with that for our own stuff.
Let's say if someone is playing with snes9x, has a ton of roms, adding a new app to the request event queue such as a defrag tool (NOT AVAILABLE YET) would defrag the hdd.
Long story short, I believe the "Request event" is the event/app in queue after one quits a game. It may even be for system events such as shutting down or something.
With the latest developments coming out in the last couple of days, has the acidcfw team changed their game plan?
With the release of geohot's firmware decryptor tool, and the coming ability to be able to sign things, how does this affect your approach?
Personally I would love it if this meant that a fully functioning cfw, complete with mkv and ntfs support is on the way from you guys.
I'm sure there will be lots of cfw's on offer, I just hope you are capable of getting in there fast. I would prefer to use a release from acidcfw, as they put in so much time and work before these new developments.
Last edited by Natepig; 12-31-2010 at 10:07 AM Reason: typo