• Steam recently changed the default privacy settings for all users. This may impact tracking. Ensure your profile has the correct settings by following the guide on our forums.

[RELEASE] Game Categories Revised

Plugin updated, edited first post.

Changes said:
- Fixed bug of PSX games not launching when they're categorized.
- Fixed some odd bug which made categories show up twice, and some other weird stuff. (I had already fixed this in a late build of v1, but most news sites published the initial build, which still had this bug)
- It will no longer show the 'Uncategorized' icon if you don't have any uncategorized games (in multi-ms mode).

About the INI file idea, I'll look in to it for version 3, I just had to release this to fix some critical bugs. ;)
 
It works with Disable XMB Plugins & Lockdown now.
However I can't get the L+R+Home to work?

How are you detecting these keys? Its probably incompatible with another plugin.
 
Hooking the sceCtrlReadBufferPositive in vshctrl stubs via FindImport.

Looks like that also is broken by delayed loading...if vshctrl loads before the plugin, which it does when Disable XMB plugins is set. Might need to FindModule till found then patch the import stub.

Its probably better to code all plugins with this in mind, cos it makes them "modular". You'll be able to unload and load them at anytime.

Additional Comment:
Another thing, if you were planning to load a module on reboot, you would need to make ALL the subfolders appear under GAME and not just the previously selected category. Otherwise homebrew wouldn't be able to access the other stuff directly under GAME normally.
 
Looks like that also is broken by delayed loading...if vshctrl loads before the plugin, which it does when Disable XMB plugins is set. Might need to FindModule till found then patch the import stub.

No, I do all my patches (IO, Ctrl, etc.) in VshControl and they work fine, in version 2 I made it FindModule at module_start for VshControl, and if it finds it it'll patch it straight away, in all other cases it waits for the module handler. VshControl should always be loaded before VshMain is loaded, so that can't be wrong. I'm currently working on a bunch of improvements for v3, which includes the INI-file stuff, but I really need a break as I've been coding for days. :p
 
I made it FindModule at module_start for VshControl, and if it finds it it'll patch it straight away, in all other cases it waits for the module handler.

Well its definitely going wrong somewhere here. If the plugin is loaded before vshctrl then the L+R+Home works, but not if its loaded after vshctrl. The particular case I'm talking about is when you've replaced vshmain.prx with a custom module and launch the real one later. Its not recommended to do stuff like FindModule in module_start (in a plugin), it can crash systemctrl (espcially crash prone in module_start when rebooting into GAME mode and your plugin is not the last one on the list).
 
Well its definitely going wrong somewhere here. If the plugin is loaded before vshctrl then the L+R+Home works, but not if its loaded after vshctrl. And its not recommended to do stuff like FindModule in module_start (in a plugin), it can crash systemctrl (espcially crash prone in module_start when rebooting into GAME mode and your plugin is not the last one on the list).

I don't think that's true, as even custom firmware modules like vshctrl call this function in module_start, and I've done so in a lot of private plugins, and I never came across any problems.
Oh well, I'll figure out later. By the way, I never saw a release of Lockdown that actually loaded the modules after vshmain, so I didn't even test this fix myself. :p Any link?
 
I don't think that's true, as even custom firmware modules like vshctrl call this function in module_start, and I've done so in a lot of private plugins, and I never came across any problems.

Its prone to crash in GAME mode when module_start takes a bit too long. Would crap out after the gameboot.
 
Its prone to crash in GAME mode when module_start takes a bit too long. Would crap out after the gameboot.

No offense, but loading plugins AFTER vshmain fails. It inherits so much patching problems. (Proof is above).

Nice work Bubbletune, hope those nids helped =P
 
No offense, but loading plugins AFTER vshmain fails. It inherits so much patching problems. (Proof is above).

Nice work Bubbletune, hope those nids helped =P

It doesnt load after vshmain. It loads the plugins first from kernel mode then loads vshmain. The only patching problems are for plugins that patch stuff in vshbridge/vshctrl as the plugins would be loaded after them.

The delayed loaded was added in Lockdown XMB Style Beta-3.
 
This is a very good.

:tup:
 
It doesnt load after vshmain. It loads the plugins first from kernel mode then loads vshmain. The only patching problems are for plugins that patch stuff in vshbridge/vshctrl as the plugins would be loaded after them.

The delayed loaded was added in Lockdown XMB Style Beta-3.

How about instead of replacing vshmain, you edit the bootconfig to load your application before mediasync, then you don't have to load any plugins, and they won't effect you ;)

I don't mean that in a harsh way, but It'll fix the problem of patching plugins and such.
 
How about instead of replacing vshmain, you edit the bootconfig to load your application before mediasync, then you don't have to load any plugins, and they won't effect you ;)

I don't mean that in a harsh way, but It'll fix the problem of patching plugins and such.

Then it will continue to load the rest of the vsh modules after my app and it will crash due to various complications!

Regardless of the reason, I still think plugins should be made as modular as possible and have the ability to be loaded and unloaded at any time. Its just good coding practice, instead of relying on a sequence of predetermined events. All my plugins can be loaded and unloaded at any time without any problem, they clean up and handle any patching accordingly.
 
Then it will continue to load the rest of the vsh modules after my app and it will crash due to various complications!

Regardless of the reason, I still think plugins should be made as modular as possible and have the ability to be loaded and unloaded at any time. Its just good coding practice, instead of relying on a sequence of predetermined events. All my plugins can be loaded and unloaded at any time without any problem, they clean up and handle any patching accordingly.

Not if you stop it. It's not difficult and fairly trivial to stop the PSP loading the rest of the firmware.

Some plugins need to patch stuff before it happens. You really shouldn't be asking developers to support your application when yourself can support all of them with a little bit of work.

I'm not trying to underwhelm your work, It's great!

I think we should stop cluttering this thread, so PM me your reply =D
 
A slight annoyance but nonetheless I figured I'd report it:

kxploited homebrew with the __SCE__ naming placed in a category folder ends up with visible corrupt icons.
 
A slight annoyance but nonetheless I figured I'd report it:

kxploited homebrew with the __SCE__ naming placed in a category folder ends up with visible corrupt icons.

I think that has to do with the homebrew name character limitation
 
I think that has to do with the homebrew name character limitation
if I add in a gew characters then both folders come up corrupt; in this case the homebrew actually runs but it's data folder shows as corrupt (despite the application of the usual __SCE__ prefix). I thought since it runs that it's different than the name length limit.
 
I'm not going to release an update for a while till I can gather enough time to do a complete rewrite and more than one improvement, as it seems there are just to many bugs out there I can't explain. I'm sorry and I'll do everything I can to release a new version as soon as possible.
 
Back
Top